|
Mike Fedyk - Optimizing Linux Performance by Phillip G. Ezolt
[Recent Entries][Archive][Friends][User Info]
|
04:35 pm
[Link] |
Optimizing Linux Performance by Phillip G. Ezolt
Today I finished reading Optimizing Linux Performance by Phillip G. Ezolt.
Even though I already knew a lot about the subject, it did fill in a few gaps in my knowledge of oprofile, kcachegrind, valgrind, vmstat, iostat, script, objdump, gdb and sar. It also clued me into a few tools I didn't know about like ltrace, gprof, memprof, ipcs and etherape.
One tool it didn't mention is dstat. The package description says it all:
<dstat>Dstat is a versatile replacement for vmstat, iostat and ifstat. Dstat overcomes some of the limitations of these programs and adds some extra features.
.
Dstat allows you to view all of your network resources instantly, you can for example, compare disk usage in combination with interrupts from your IDE controller, or compare the network bandwidth numbers directly with the disk throughput (in the same interval).
.
Dstat also cleverly gives you the most detailed information in columns and clearly indicates in what magnitude and unit the output is displayed.
.
Dstat is also unique in letting you aggregate block device throughput for a certain diskset or network bandwidth for a group of interfaces, i.e. you can see the throughput for all the block devices that make up a single filesystem or storage system.
.
Dstat's output, in its current form, is not suited for post-processing by other tools, it's mostly meant for humans to interpret real-time data as easy as possible.
One thing about dstat is that it uses six times more memory than vmstat (but the output is prettier):
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
mfedyk 23001 0.6 0.5 5452 3824 pts/5 S+ 21:27 0:00 python /usr/bin/dstat 1
mfedyk 23027 0.0 0.0 1780 588 pts/6 S+ 21:28 0:00 vmstat 1
</dstat>
I liked the examples used to for discovering performance problems but not most of the solutions proposed. I understand the point of the book isn't detailing the way optimize your system libraries (glibc, gtk, etc.), but building menu caches in nautilus (the latency performance example) might have gone over better with me if there was at least a mention of improving the library being called. Sometimes the best course of action is to improve the library you're calling in the Open Source Way(tm) instead of just working around problems you find in your application code.
The book also shows areas where Linux and its performance tools could be improved. It got me thinking about how to change the entire Linux performance monitoring ecosystem by first griping about how things are currently and pontificating on how things would be with a few changes.
Right now, every performance monitoring system (cacti, munin, etc.) has it's own performance gathering code. sysstat's sar (System Activity Reporter) is already written in C. It needs to store more statistics and have language bindings to Perl, Python, Ruby, PHP, etc. for polling its database, and a generic stats reporting API for stats gathering agents like snmpd, etc. This would allow one project to be the focal point for system monitoring statistics gathering and remove the duplication of work.
With this work done, performance monitoring *might* be close to what windows currently offers. I don't say that lightly. This is a serious area where Linux needs to catch up.
gnome-system-monitor (g-s-m): The lines are so thick it looks like they were drawn with a crayon. Vital stats like nice, system, hard and soft irq cpu usage are not shown. So much vertical space is wasted with the child sized buttons to change the colors of the lines. At least it doesn't flicker when updating its stats anymore. This tool has improved steadily over time but still needs a lot of work. Compare this with Windows' Task Manager. While not the best, it does present more information in less screen space than g-s-m.
Also since the book was written when Fedora Core 2 was current, there have been a few things that have improved since the book was written. For instance, major and minor faults are accounted for properly now. Let's get that per process block and socket/pipe statistics gathering into the kernel.
Tags: linux, optimizing, performance, phillip g. ezolt
|
|
| |
| From: | (Anonymous) |
|---|
| Date: | June 2nd, 2007 12:43 pm (UTC) |
|---|
| | dstat memory usage | (Link) |
|
As the author of dstat I can explain you why dstat uses more memory than vmstat. Obviously since it is using python, there is that overhead. But because it is much more flexible than vmstat, it is bigger as well.
If you look at the cpu usage, dstat can do much more than vmstat and depending on what functionality you enable the overhead is bigger. Because it is flexible the differences depend on the options and usage.
dstat was never intended to be the most optimized tool, neither for cpu or memory usage. It is intended to be more useful than other tools, have a plugin system for adding counters and is easy to extend using python.
I would suggest looking at the possibilities vmstat offers because whatever you read about it may not have shown it capabilities nor uses. |
|
![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
mfedyk's journal
