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