profiling stats for samba
David Collier-Brown
David.Collier-Brown at canada.sun.com
Wed Oct 4 17:22:15 GMT 2000
Herb Lewis wrote:
>
> I would like to propose the following structure for profile.h as the
> list of stats that will be collected when profiling is enabled.
I'm assuming you mean profiling in the narrow sense, that
of hunting down particular hotspots in samba.
> I would
> like suggestions on what other stats should be collected. Jeremy
> indicated he would like the execution time for processing SMB
> transactions. Do we want the time for every SMB? Do we want the time
> split into system and user?
The stats I collect(ed) for whole-system performance
were quads of (initial request time, first i/o time,
last i/o time, bytes transferred) for file read and write.
These were written (via buffered i/o) to a seperate
log and postprocessed to give latency and throughput.
These were effectively system+user, and the only ones
I collected were file transfer ones: the next cantidate
was directory operations. Most of the others were
"short" (ie, only interesting if they went utterly whacko).
and were not considered. The ones in between were
things that PCs often do, like directory scan/stat
and renaming xxx.foo to xxx.bat.
> Currently this is implemented as a shared memory segment so the
> display agent can obtain the info later. All smbd's write into this
> with no locking to reduce overhead. Since this is not critical data
> it doesn't really matter if we ocassionally step on each other while
> bumping a counter.
That's pretty sane: I've seen some fairly complex stats
(wait queue length and occupancy) saved in simple
variables with neglible cost. Only a few things need
to be logged sequentially.
> Do we want to collect indivual stats for every smbd
> that is running or maybe be able to specify a particular smbd that
> should be the only process updating the counters? Currently the size
> is 584 bytes for the structure. If we want individual stats for all
> smbd's what do people recommend for storing these - tdb, mmap file,
> etc.?
Hmmn: if this is mainly to be used by developers and
tuners, one set is sufficient, because you can do a
controlled-load test with a known number of smbds, and
just divide them out. This is less good if you are
trying to diagnose a particular client in a production
site, though: I'd probbaly make it per-smbd, and turn on
the proper smbd with a %-variable in the option.
>
> Finally, once all this is completed, should this be left as a compile
> time option or should we add a runtime test for a pointer being
> non-null to every function where stats are gathered? I may actually
> try this later and run NetBench to see what the performance degrad
> will be.
I'd suggest a --with option at least initially... but
see if you can save them unconditionally, preferably
at a cost approximately equal to testing a pointer (;-))
>
> I have also implemented a Performance Co-Pilot collection agent to
> display these stats that I'll probably check into the samba tree
> when it is complete.
>
> I would appreciate feedback and suggestions from all.
Suggestions? Sure: worth what you pay for them though!
--dave
--
David Collier-Brown, | Always do right. This will gratify some people
185 Ellerslie Ave., | and astonish the rest. -- Mark Twain
Willowdale, Ontario | //www.oreilly.com/catalog/samba/author.html
Work: (905) 415-2849 Home: (416) 223-8968 Email: davecb at canada.sun.com
More information about the samba-technical
mailing list