profiling stats for samba

David Collier-Brown David.Collier-Brown at
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 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!

David Collier-Brown,  | Always do right. This will gratify some people
185 Ellerslie Ave.,   | and astonish the rest.        -- Mark Twain
Willowdale, Ontario   | //
Work: (905) 415-2849 Home: (416) 223-8968 Email: davecb at

More information about the samba-technical mailing list