Ok...I believe I've found the culprit. After having tracked emalloc calls and only being able to come up with almost _exactly_ half the memory actually being allocated, I took a look careful look at store_load_plugin and the associated nvti* routines and the g_* routines.
It turns out there's a major memory leak in nvti_from_keyfile, which results in each key being allocated twice, once by the glib routines, and once by the nvti_set_* routines. The pointer allocated by the glib routines is simply passed in to the nvti_set_* routines, and then lost, but it needs to be actually retained, so that it can be freed after calling nvti_set_*. The end result was that cache file information was allocated twice, but only freed once. I'll test and submit a patch once I get it fixed up. That should cut things down to about half the size, and improve the situation significantly. Thomas Jan-Oliver Wagner wrote: > On Friday 03 September 2010 00:00:37 Thomas Reinke wrote: >> I'll continue to poke around to see what optimizations >> I can come up with over the weekend to improve the >> situation. > > thanks for starting to work on this. > There are many, many ways to optimize still left. > E.g. it is not really necessary to keep the description > in memory at all. > Unfortunately the code we inherited is not really helpful > to allow changes easily. > > I planned to work on this in more detail after we have > the rest of the framework in place. Seems you are in > need of this earlier. > > My actual idea to get the memory footprint low is > to have openvassd only care about scanning and not > do other things. The 4-commands idea we discussed at > the last OpenVAS DevCon. > > Best > > Jan > _______________________________________________ Openvas-devel mailing list Openvas-devel@wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-devel
