On Wed, Aug 14, 2013 at 5:48 PM, Dennis Peterson <denni...@inetnw.com>wrote:
> On 8/14/13 2:23:28PM, David Raynor wrote: > >> >> I'll look a bit more at how we are loading the interim signature state and >> see what else we could do with the sorting. Meanwhile, this is a change >> you >> could put into practice now and get faster startup times. Before making >> any >> change on a server directly, you can test a modified DB with clamscan to >> see the difference. >> >> My testing VM is 64-bit Debian, if it matters. >> >> Hope this helps, >> >> Dave R. >> >> >> I presume reloading signatures into an existing daemon instance is a > blocking event. Is it possible to instantiate a new instance and migrate > the socket to that instance once the update is completed, and then kill the > stale daemon? I really don't care much about load times to be honest (> 5 > minutes on older SPARC systems) but do care about memory as I have it > running on some pared down but very reliable hardware here and there. > > dp > > ______________________________**_________________ > Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net > http://www.clamav.net/support/**ml <http://www.clamav.net/support/ml> > It does block the receive-loop thread to perform the reload, but while it is reloading any already active worker threads continue their work with the old engine. They are tracked by reference count, so the old engine is not actually freed until its reference count hits zero. The last thread with a reference is the one that actually frees the memory. Side note: I assume you have self-check reloads disabled on those SPARC systems? Dave R. -- --- Dave Raynor Sourcefire Vulnerability Research Team dray...@sourcefire.com _______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
