Tim Brown wrote:
> On Thursday 02 September 2010 19:42:54 Thomas Reinke wrote:
>> Ok...have some additional information to add now -
>> it would seem that a raw start up of Nessus was consuming
>> approximately 20M.  The same start-up on OpenVAS
>> consumes >100M.  It also seems that the child processes
>> are constrained by the maximum size of that startup,
>> i.e. we never see the memory of an actual script
>> processing task exceed that memory usage.
>>
>> The factor of 5 (approximately 4K memory consumption
>> per script in the test suite) appears to be what is
>> causing the difficulties.  Each client connecting
>> to the scanner eventually moves, from what we can tell,
>> from a small memory foot print up to the maximum of
>> it's parent.  That in turn translates to each child
>> task handling the nasl script process eventually having
>> a larger and larger memory footprint.
>>
>> It means that to avoid swapping
>> on a box, a 1 Gig platform is limited to approximately
>> 10 concurrent tasks.  That's a pretty significant
>> hit.  Any way of knocking that memory consumption
>> back down?  I'm not sure assuming that folks have 4Gig+
>> in their scanning platform is a reasonable assumption.
> 
> Wow, that sounds pretty nuts.  Some of it may be attributed to more NASLs 
> being loaded but even so, it sounds like something is broken somewhere.  Any 
> chance of attaching something like valgrind to it to see if there are any 
> obvious areas of concern?
> 
> Tim

We're digging into it now.  More nasl's doesn't really account
for the differential problem we're seeing between Nessus and
OpenVAS - since we're using the exact same test suite.
We've already added dump logic on the emalloc calls to see
what's going on, and that alone is showing a straight forward
45 Meg consumption by the time openvassd is ready to accept
connections (and that ignores the overhead of malloc itself,
which IIRC is 4 bytes per call, and would add about another 4 Meg
to that total).

Thomas


_______________________________________________
Openvas-devel mailing list
Openvas-devel@wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-devel

Reply via email to