Starting OpenVAS 22.04 is slower than starting OpenVAS 20.04

Building from Source and Advanced Topics
1

GVM versions

gsa: v22.4.0
gvmd: v22.4.0
openvas-scanner: v22.4.0
gvm-libs: v22.4.0

Hardware specs

Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
CPU(s): 1
Thread(s) per core: 1
Core(s) per socket: 1
Model name: AMD EPYC 7642 48-Core Processor
CPU MHz: 2299.998
RAM Gb: 2.052384

Environment

Operating system: Debian Bullseye
Kernel: Linux SLDB-GVM 4.19.0-18-amd64 #1 SMP Debian 4.19.208-1 (2021-09-29) x86_64 GNU/Linux
Installation method / source: from Source, using this guide

Greetings!
I attempted to build OpenVAS 22.04 and ultimately obtained one functional single docker container version. I noticed, as Bricks previously mentioned here, that for every OpenVAS container instantiation there exists, indeed, a temporal overhead (around 7 to 10 minutes). That happens due to the fact that the NVTs need to be loaded into Redis. I did experiment however with the previous OpenVAS 20.04 version, building a docker image, all while following the same procedure (apart from starting Notus and MQTT, specific to the 22.04 version). Upon investigation, I noticed that for every container instantiation, while using the same system with the exact same specifications, although it still takes some time for the NVTs to be loaded into Redis, that period of time tends to be shorter (around 3 minutes).
Since I intend on using this container within a bigger app, in which an OpenVAS scan runtime is quite a significant variable, I would like to inquire: is it known as an usual fact for the NVTs loading to last longer in the latest version than in the older ones? Or am I doing something wrong and it should still last around 3 minutes? I tried inspecting the gvmd and ospd-openvas source code, but failed to identify a clear culprit. Still, I’m guessing it might be linked to the execution time of the load_vts_into_redis() function from ospd-openvas daemon. This is a wrapper for creating a subprocess to execute openvas --update-vt-info, but I’m not quite sure if I understand what is happening behind this.
If there’s no way optimizing the NVTs loading time, could you at least help me understand why the overhead is, counterintuitively, longer in the latest version than in the older one?

Thank you and have a great day!

2

New version means new features. But 7-10 minutes sounds like a mis-build. You need more resources as well 8GB RAM and not 2 would be a good start as well 4 CPU cores. But you need to investigate your uncoordinated integration by your self, use the system tool like strace, sar, iostat to see what is taking the time. Additional IO performance is key as well. Even if you run in a container you should aware of the needs of the application and don´t even think about syncing Redis to the disk :wink:

1 Like
3

The VT information is gathered from .nasl files. These .nasl files are loaded by the openvas scanner executable that is run by the ospd-openvas daemon once on startup and if the plugin_feed_info.inc file has changed. The scanner is run with the --update-vt-info that reads all the .nasl files and puts their meta data into a redis db. ospd-openvas itself can’t read or run .nasl files.

That the load time of nasl files can diverge between openvas scanner versions can always happen. 22.04 will still get bug fixes that might change some internal behavior. As far as I know we don’t measure the startup time especially as it is only costly when loading the .nasl files initially. Since the last release the openvas-scanner got some changes already. Therefore you could try to build and compare the current code from the stable branch.

2 Likes