trAvis - MANAGER

Edit File: performance.txt

= Dstat performance == Introduction Since Dstat is written in python, it is not optimized for performance. But that doesn't mean that Dstat performs bad, it performs quite good given its written in python and a lot of dedication went into profiling and optimizing Dstat and Dstat plugins. But when doing performance analysis, it is always important to verify that the monitoring tool is not interfering with the performance numbers. (eg. writing to disk, using cpu/memory/network, increasing load) == Compare with baseline Depending on the plugins being used and the load on the server itself the impact Dstat has on the system you are monitoring might be considerable. A lot of plugins are pretty fast (less than 0.1ms on an modest 1.2Ghz laptop), but some plugins may use up to 3ms or even up to 2% of your CPU. (eg. each top-plugin scans the process-list) Before performing any tests please verify for yourself what impact Dstat has on your test results and keep that in mind when analysing the results afterwards. Especially if you suspect Dstat to be influencing your results, do a baseline with and without the Dstat commandline. == Selection of plugins In case the impact is higher than expected, reduce the number of plugins and remove expensive plugins, or even better, look at the plugin you're using and send me optimizations. Newer python versions are also faster than older ones, and hardware is only becoming faster at a pace that these considerations may not hold anylonger. == Debugging and profiling Dstat If you need feedback about plugin performance, use the --debug option to profile different plugins. If you use -t together with --debug, you can see the time deviation on your system in relation to load/plugins. If you want to profile certain plugins, you can use the --profile option which provides you with detailed information of the function calls that are the most expensive. You can also run the dstat plugin (--dstat) to look what overhead (cputime) and response (latency) Dstat has during runtime, which can be very useful to compare with your baseline and the system in idle state. One common way to profile a single plugin is to use the following commandline: dstat -t --dstat --debug --profile dstat -t --dstat --top-cpu --debug --profile The default profiling infrastructure is quite expensive, so it is important that you first make a baseline including the profiling itself, then compare it against the same commandline including the plugin you want to profile. == Improving Dstat's footprint even more Another way to win a few CPU cycles is to pre-compile the Dstat plugins by running the compileall.py script that comes with python on your plugins directory. It can save about 10% in execution time. Remember that invisible plugins (that run out of your terminal window) do take up cycles because the information is still being collected and possibly written to CSV output. It should be possible to write plugins in C to improve the impact on the system, but I have no experience with writing python modules in C. Any feedback on this is welcomed. == Performance tuning The following documents may be useful to tune a system for performance * http://people.redhat.com/alikins/system_tuning.html[] NOTE: Please send me improvements to this document.