[Openvas-devel] Memory footprint for openvassd
lists at securityspace.com
Fri Sep 3 00:00:37 CEST 2010
Jan-Oliver Wagner wrote:
> On Thursday 02 September 2010 22:51:54 Thomas Reinke wrote:
>> 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.
> please have in mind that OpenVAS stores more meta
> information about NVTs than Nessus does.
Yes, we've noticed as we dig through the nvti* routines
and how the cache works. That being said, it's a bit
of an issue right now for us, and probably will be for
others later, if the daemon chooses to cache so much
information in memory as to make it impossible to run
any decent work load on the box. We can easily enough upgrade
memory on our boxes, but most of our platforms are
a bit older (as in a couple of years) and have MB's with
2 Gig limits. That still won't cut it with what's
Personally I'm just trying to get my head wrapped around
what information is cached, why it is cached, and whether
or not certain information can be chucked in favour of
a delayed load.
1. Some information never needs to be loaded unless a
client asks for a complete list via
"CLIENT <|> COMPLETE_LIST <|> CLIENT"
E.g. copyright data, if chucked unless needed,
saves 2.4 Meg (from a starting position of 110,180K
down to 107,780K.
2. Revision string. Again, if not loaded unless
explicitly needed, will save almost 1 Meg.
3. Descriptions. While we happen to always ask for
full descriptions in our client, we are actually
looking at not doing that if we know there have been
no updates. In that situation (where we know the
version of the plugins installed, there is no need
to hold descriptions for tens of thousands of tests
in memory, when only a handful will ever trip.
A delayed load would save gobs of memory here.
Simply put, the daemon must be from a memory basis more
light weight than what is happening here.
I'll continue to poke around to see what optimizations
I can come up with over the weekend to improve the
More information about the Openvas-devel