management of Samba4

[David Collier-Brown]

James Peach wrote:
> Hmm .. I'm thinking twice about this now. Say we have 1000 smbds
> running. We have a monitoring app that is sampling performance
> metrics every second. If one of the values the app is calculating is the
> total number of SMB packets, would this require 1000 round trips per
> second? If so, what happens when the app needs more metrics?
> 
> In this proposal, each time the the app requests a metric, an smbd has
> to stop serving clients (briefly) to service the request. A couple of
> these now and then wouldn't matter, but regular sampling of large
> numbers of metrics or large numbers of smbds might be a problem.  The
> cost of sampling the metrics with the scheme is proportional to the
> sampling rate and the number of metrics being sampled (O(n^2)??).

	Yes, although it's more the rate times the number of smbds sampled,
	more like c*n^2, where c is the constant cost of collecting a
	vector of metrics to deliver.  It indeed scales rather poorly

	You really need to accumulate the data in a low-cost
	way, and then deliver it cheaply, at a frequency about
	twice that of the sample period desired.  This implies
	rolling up the data, which is computationally expensive,
	and is best left in the monitoring program, not the app
> 
> If performance metrics are enabled, each smbd will have to gather the
> data irrespective of whether any sampling was occurring. This is a
> fixed cost, but for simple counters, it's probably not very high. In a
> scheme like a shared memory segment or shared mmap, samba does not pay
> the cost of sampling the metrics, only the cost of gathering them
> (which is a fixed cost however you arrange your metrics).
	
	The traditional approach is to have a bunch of free-running
	counters, and have the monitor sample the values and
	subtract to get the <whatever>/second values. This is order n.
	
        Alas, this doesn't work well with units involving time or 
	percentages: you have to do a rolling average in
	the program being observed to get useful values for 
	the monitor. \

> 
> So I think this proposal will work well for smbstatus-style apps, and I
> can imagine building a really useful samba debugger on top of it. I'm
> not sure it is suitable for exporting performance statistics, however.


	In a TPS monitor, I kept the computation cheap in the
	monitored program, only doing work if someone was monitoring,
	and wrote the data to a log via buffered async I/O,
	thus avoiding doing much arithmetic in the application,
	letting the collected data buffer up, and be flushed only
	when the buffer filled.  This was order c*n, and the
	monitor scaled by n systems observed. A cute way to
	move the n^2 out of the application itself into
	the monitor.

	I also considered (and used) polling in one case, but
	it made a long synchronous code path, so it interfered
	with both performance and measurement. I may come back 
	to it later if I can make it cheap.  This was c*n for
	the app, c*n^2 for the monitor, too.

--dave (anal performance guy) c-b
-- 
David Collier-Brown,      | Always do right. This will gratify
Sun Microsystems, Toronto | some people and astonish the rest
davecb at canada.sun.com     |                      -- Mark Twain
(416) 263-5733 (x65733)   |