High number of parallel DB connections when opening Business Process Dashboard

[ngoeddel-openi]

Describe the bug

When opening the Business Process Dashboard, the code triggers an apply() call for every defined business process. Each call runs complex SQL SELECT queries against the IcingaDB instance.

With a larger number of business processes (or processes referencing many hosts/services), this results in a linearly increasing number of parallel connections to the IcingaDB database.
In our environment, this frequently causes us to hit the max_connections limit on the MariaDB instance.

Analysis

Excerpt from library/Businessprocess/Web/Component/Dashboard.php::

foreach ($processes as $name) {
    if (Module::exists('icingadb') &&
        (! $bp->hasBackendName() && IcingadbSupport::useIcingaDbAsBackend())
    ) {
        IcingaDbState::apply($bp);
    } else {
        MonitoringState::apply($bp);
    }
}

Inside IcingaDbState::apply(), yieldAll() is used to fetch service and host data from IcingaDB:

foreach ($this->backend->yieldAll($services->assembleSelect()) as $row) { ... }
foreach ($this->backend->yieldAll($hosts->assembleSelect()) as $row) { ... }

It appears that a new query (and connection) is opened for each configured process. Additionally, Redis lookups are performed for fresh state data but do not replace the database queries — they are executed in parallel.

Impact

• Parallel DB connections grow linearly with the number of processes.
• Short-lived spikes in Threads_connected can cause performance degradation or even connection errors when max_connections is reached.
• Particularly problematic in distributed setups or when no connection pooling is in place.

To Reproduce

1. Define multiple business processes (e.g., 50+).
2. Open the Business Processes dashboard in IcingaWeb.
3. Monitor the DB connections — the number of active connections spikes sharply.

Expected behavior

• Reuse existing DB connections (pooling) or process items sequentially to avoid spikes.
• Optionally allow configuration of a maximum parallelism threshold for queries.

Workarounds

• Increase max_connections in MariaDB.
• Use a connection pooler like ProxySQL or MariaDB MaxScale.
• Reduce dashboard refreshes during high-traffic periods.

Screenshots

This is what I see when running SHOW FULL PROCESSLIST; at the right time:

Your Environment

Include as many relevant details about the environment you experienced the problem in

• Icinga Web 2 version and modules (System - About): 2.12.4
• Web browser used: Chrome
• Icinga 2 version used (icinga2 --version): 2.14.5-1
• PHP version used (php --version): 8.2.28
• Server operating system and version: RHEL9

Additional context

Add any other context about the problem here.

[nilmerg]

Hi,

there is no parallelism anywhere in Icinga Web as PHP does not support this. Everything is processed sequentially, maybe asynchronously, but still sequentially.

What you may noticing is an old behavior of Icinga DB Web. If you'd have included its version (plus the one of businessprocess) I'd be sure.

Newest versions of both do not open multiple database connections per request, a single connection is used to query the database sequentially, and in case of 50 processes, 50 times still, but that's of course expected.

So, make sure to update Icinga DB Web and businessprocess to the latest version.

[ngoeddel-openi]

That's good to hear!

Here are the module versions:

• businessprocess: 2.5.1
• icingadb: 1.1.2
• cube: 1.3.3
• director: 1.11.5
• incubator: 0.22.0

So it sounds like I have to update icingadb to 1.2.2 and businessprocess to 2.5.2 then and the issue should be solved?
Then I have to look for our next update window in that setup and see which other dependencies also have to be updated or if it just works with only updating these two modules.

[nilmerg]

Yes, 1.1.2 is a bit old, there's even a 1.1.3 available. But yeah, to avoid duplicated connections it is required to update to 1.2.2.