[Openvas-devel] Memory footprint for openvassd

[Thomas Reinke]

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
happening here.

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.

For example,

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
situation.

Thomas