[tahoe-dev] profiling, part 3 -- server side
zooko
zooko at zooko.com
Mon Sep 24 14:39:45 PDT 2007
Folks:
While my tahoe node was uploading ten files of 1 mebibyte each,
Brian's tahoe node was acting as a storage server, accepting shares
from each file and writing them to its disk. Our two computers were
connected by my home DSL line, through the Internet, to the Allmydata
HQ office DSL line, to Brian's computer. It is an Athlon64 3500+ in
32-bit mode, and it was running the excellent Linux tool oprofile
[1], which samples the entire system's behavior. Afterward, these
were the stats for which function was in use when the samples were
taken.
CPU: CPU with timer interrupt, speed 0 MHz (estimated)
Profiling through timer interrupt
samples % app name symbol name
365733 91.2007 vmlinux default_idle
5046 1.2583 libfreetype.so.6.3.16 (no symbols)
2613 0.6516 libgdk_pixbuf-2.0.so.0.1000.13 (no symbols)
2119 0.5284 libart_lgpl_2.so.2.3.19 (no symbols)
1152 0.2873 libglib-2.0.so.0.1400.1 (no symbols)
949 0.2366 Xorg (no symbols)
935 0.2332 libgobject-2.0.so.0.1400.1 (no symbols)
890 0.2219 perl (no symbols)
771 0.1923 python2.4 PyEval_EvalFrame
681 0.1698 libpixman-1.so.0.9.5 (no symbols)
659 0.1643 emacs22-x (no symbols)
585 0.1459 libz.so.1.2.3.3 (no symbols)
575 0.1434 libc-2.6.1.so memcpy
463 0.1155 libc-2.6.1.so _int_malloc
372 0.0928 libgtk-x11-2.0.so.0.1000.13 (no symbols)
367 0.0915 libmozjs.so (no symbols)
360 0.0898 librrd.so.2.0.9 (no symbols)
358 0.0893 firefox-bin (no symbols)
353 0.0880 vmlinux fget_light
340 0.0848 python2.4 lookdict_string
337 0.0840 libc-2.6.1.so strcmp
336 0.0838 radeon_drv.so (no symbols)
335 0.0835 vmlinux acpi_pm_read
330 0.0823 libgdk-x11-2.0.so.0.1000.13 (no symbols)
320 0.0798 libcrypto.so.0.9.8 (no symbols)
309 0.0771 forcedeth (no symbols)
265 0.0661 vmlinux do_select
259 0.0646 libcairo.so.2.11.5 (no symbols)
253 0.0631 vmlinux unix_poll
248 0.0618 libX11.so.6.2.0 (no symbols)
238 0.0593 vmlinux handle_IRQ_event
Hm, I see that Brian's computer was estimated at 0 MHz and was using
timer interrupt. He must have fallen afoul of the issue mentioned in
the oprofile faq, "Why is OProfile in timer mode on x86?". I think
that the consequences of that are two-fold: 1. code which is non-
interruptible is invisible to the profiler, and 2. there might be
more skew in which the code that gets blamed in the profiling results
is actually the code that ran right after the expensive code. I'm
not sure about that. Anyway, these results are probably reliable
anyway.
http://oprofile.sourceforge.net/faq/
Anyway, these results show that tahoe acting as a server uses up
minimal CPU -- probably around 2%, even if some of the libc, libz, or
vmlinux costs can be attributed to the Tahoe node.
Regards,
Zooko
[1] http://oprofile.sourceforge.net/news/
More information about the tahoe-dev
mailing list