As a follow-up to previous thread, we did a bit of digging into openvassd to find where all the memory has gone, and came up with one rather inelegant way of dropping the memory consumption by about half again. In our case, this means dropping memory consumption to the low 30Meg range/High 20Meg (depending on exactly what we do).
In terms of a summary description of what happens, when connecting to the daemon, it spits back a lot of information such as Descriptions, Revision numbers, Families, summaries, etc. The catch is that in most cases, we (as in SecuritySpace) don't use them. We have one instance of openvassd that is not used to scan, but only to pick up this text information and record it in a location for presentation on the web side of things. When an actual scan, however, is run, we connect to a completely different set of scan daemons. While they too get all this data, they don't care about it - they only care about the list of plugins that get returned so that they can properly launch scans. So, the hack would involve adding a config item to openvassd.conf that tells it to operate in "lean" mode, in which case strings that are never used during the course of a scan are not loaded into memory. As said earlier, this would cut the foot print rather drastically. Of course, the general use situation problem here is that if the scanner is configured in that mode, and a client then connects and expects to get this data back, it would get it. We (I) like the originally described hack, because it fits our usage situation, and it hits the sweet spot of being an incredibly trivial patch to implement, with a big pay-off in terms of memory reduction. But if we put a patch like this together, will anyone else have use for it? I don't like having a patched version of the daemon (I'd prefer to be able to standardize on the openvassd as officially distributed). But I don't like having functionality added to openvassd that isn't usable by anyone else, either. Comments? Thomas _______________________________________________ Openvas-devel mailing list [email protected] http://lists.wald.intevation.org/mailman/listinfo/openvas-devel
