dccd memory usage

Richard Underwood richard@aspectgroup.co.uk
Tue Oct 5 10:05:26 UTC 2004


> That sounds strange.  Memory exhaustion could reasonably lead 
> to thrashing, but should not kill dccd.
> 
	I probably wasn't clear enough - it was the server which died, not
dccd. Your point still stands, memory exhaustion shouldn't kill it. I'm
hoping a kernel upgrade will have fixed the problem.

> The easiest measure of dccd speed is "ms delay" value from 
> `cdcc stats` That value is the recent avarage time from 
> reception of a request to transmission of the correspondig answer.
> 
	0 ms!

> The only control on the size of the database is what dbclean 
> imposes. Dbclean tries to fit the database into about half of 
> available RAM, with some fudge factors for systems with more 
> than 1GByte.
> 
	Ah, I see - so the database is limited to the "window" of 1501M?

> Are better knobs needed?
> 
	I think it would be useful to know a bit more about it. If dbclean
limits the db size to 1501M for my server, and 500M for a server with 1G,
does it mean one server is more effective as a dcc server?

	If not, then there must be an optimum where the db size is big
enough to be efficient, but not using more memory than necessary.

	I'm also not 100% convinced about locking the database into memory -
modern operating systems have pretty efficient disk caches which will have
much the same effect when there's spare memory, but give up the memory when
required. I'm open to being persuaded, though.

	The real issue is that this server isn't just a dcc server. If it
was, I don't think there'd be a problem. If it was required, I could
increase the memory to 3G, but if this triggers dccd to use 2.5G, then I get
no overall benefit (other than dccd having more memory - which I don't know
enough about to judge) - the other processes are still limited to 500M.

	Thanks,

		Richard



More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.