GOS 20.08: Introduction to Scan Queueing

With GOS 20.08, a scan queueing feature was implemented.

Use Case

  • Preventing scans from overloading the system and from starting scans at inappropriate times (e.g., during a feed update)

Background Information

Scans are only started if sufficient system resources are available. The available resources depend on the GSM model, the GOS version used, and the current workload of the system.

The most relevant resource for scanning is random-access memory (RAM). Each scan requires a certain minimum of RAM to be executed properly. A scan process does not handle multiple scans from different users or even from the same user. A scan is only started if 1100 MB RAM are available.
Due to its physical limits, RAM cannot be shared in a satisfactory way.

CPU, network connection and disk I/O are relevant system resources as well. However, unlike RAM, they can be shared at the cost of slower scan execution.

The system performance charts on the GSA’s page Performance provide detailed information about the RAM over time.

Changes on the Web Interface (GSA)

If too many scans are started and running at the same time and not enough RAM (1100 MB) is available, scans are added to a waiting queue after starting them.
The following status bar is displayed on the GSA for a task in the waiting queue: statusbar_queued

When the required RAM is available again, scans from the waiting queue are started, following the principle “first in, first out”.

The workload management is subject to the scanner. If a master-sensor setup is used, each sensor manages its available resources on its own. Sensor scans affect the scanning capacity of the master only minimally.

Performance Improvements

Due to scan queueing as well as other architecture improvements, the number of scans that can be run simultaneously has been increased in GOS 20.08 when compared to GOS 6.0. On a GSM 400 we measured more than twice the capacity with GOS 20.08 compared to GOS 6.0.