ClickHouse Pool Saturation vs Traffic Burst, ClickHouse

​

At a glance

This card lines ClickHouse connection-pool saturation up against the storefront traffic burst that is driving it, row by row, so you can see when the database is about to become the bottleneck during exactly the windows that matter for revenue. Pool saturation alone tells you the database is busy; the traffic context tells you whether that busy-ness coincides with a sales-critical moment (a campaign send, a flash sale, a homepage feature). When saturation crosses 90% while traffic is bursting, queued connections start to wait, dashboards and analytics-backed storefront features stall, and the slowdown lands at the worst possible time. This is the join between an infrastructure metric and a commercial one.

​

Calculation

-- Pool saturation side of the join
SELECT
    toStartOfInterval(event_time, INTERVAL 1 MINUTE) AS bucket,
    max(CurrentMetric_TCPConnection + CurrentMetric_HTTPConnection) AS active_conns,
    round(100 * active_conns / {max_connections}, 1)               AS saturation_pct
FROM system.metric_log
WHERE event_time > now() - INTERVAL 15 MINUTE
GROUP BY bucket
ORDER BY bucket

​

Worked example

1. The cause is the campaign, not a leak. Saturation tracks the traffic curve exactly, rising from 48% to 97% as the campaign-driven session surge hits the storefront and every session fans out into analytics-widget queries against ClickHouse.
2. The pool is the bottleneck, not the queries. Individual query latency is still acceptable; the problem is that there are not enough connection slots, so new requests queue. This shows up as a small rise in Query Latency p95 (ms) from queue wait, not from heavy queries.
3. This is the revenue-critical window. The campaign exists to drive sales; if the storefront widgets stall now, the campaign’s own traffic is degraded. That is why this conjunction pages, where a quiet-hour 97% would not.

Why saturation hit 97% during the burst:
  - Baseline: ~96 active connections (48% of 200)
  - Campaign send at 11:00 -> session surge -> +1 ClickHouse query per widget per session
  - Peak: 194 / 200 connections in use, ~6 slots free
  - Effect: new requests queue for a slot -> p95 creeps up from queue wait
  - Mitigation options, in order of speed:
      1. Raise max_connections headroom for predictable campaign windows
      2. Cache the widget queries at the edge so each session does not re-hit ClickHouse
      3. Pre-warm / pre-scale ahead of the scheduled 11:00 send next time

1. Saturation is only a crisis in context. 97% at a quiet hour is a tuning note; 97% during a campaign burst is revenue at risk. This card supplies the context that turns a number into a decision.
2. Pool exhaustion delays queries even when the queries are fine. The fix is connection headroom or fewer connections, not query tuning, when latency rises from queue wait rather than heavy work.
3. Known bursts should be pre-empted. Scheduled campaigns are predictable; pre-scaling or caching ahead of the send turns a recurring amber into a non-event.

​

Sibling cards

​

Reconciling against the source

Read the live connection counts in clickhouse-client:

SELECT metric, value FROM system.metrics
WHERE metric IN ('TCPConnection', 'HTTPConnection', 'MySQLConnection', 'PostgreSQLConnection')

Compare against the configured ceiling with SELECT name, value FROM system.server_settings WHERE name = 'max_connections'. For the time-bucketed view the card uses, query system.metric_log for CurrentMetric_TCPConnection and CurrentMetric_HTTPConnection over the window. On ClickHouse Cloud, the same metrics are visible in the SQL console, and the managed monitoring view surfaces connection utilisation; the traffic-burst side of this card comes from your storefront connector, not from ClickHouse, so reconcile that half against the storefront analytics.

​

Known limitations / FAQs

​

Tracked live in Vortex IQ Nerve Centre