What peak system load tells you about your VICIdial box

The peak system load figure in the Server Performance Report is the highest run-queue depth recorded during your shift window, and comparing it against your server's core count tells you whether the box was comfortably ahead of the work or genuinely running out of room.

What load average actually measures

System load average is a count of processes that are either actively using a CPU core or waiting in the run queue to get one. Think of it as the depth of the line at the ticket window. A load of 1.0 on a single-core machine means exactly one process is always in use or waiting. On a four-core box, a load of 4.0 means every core is fully occupied. The VICIdial Server Performance Report samples this value every five seconds and records the highest reading it sees across the full shift as the peak load.

VICIdial runs several concurrent processes at any moment — Asterisk handles audio bridging, the dialer engine manages Predictive dialing pacing, keepalives poll agent state, and the web server handles browser requests. Each of those processes competes for CPU time, so load climbs naturally as call volume rises.

Reading peak load against your core count

The golden rule: peak load near or above the box's core count means you hit saturation at least once during that shift. Here is how to interpret it in practice:

• Peak load well under core count (say, 2 on an 8-core box) — plenty of headroom, box is not the bottleneck.
• Peak load at 60–80 % of core count — healthy busy; worth watching if you plan to add agents or raise the Dial level.
• Peak load at or above core count — the box queued more work than it could immediately serve; calls may have experienced audio latency or agent screen lag.
• Peak load two or more times core count — sustained saturation; provisioning a larger server or splitting campaigns across a second box is overdue.

Transient spike vs capacity ceiling

A single high peak does not automatically mean you need bigger hardware. Context matters. Cross-reference the peak load timestamp against the Asterisk Channel count graph. If the channel count also spiked at the same moment, you had a genuine surge of concurrent calls and the load spike is proportional and expected — it is the box doing real work.

If the peak load is high but channels were flat or low at the same time, a runaway process or stuck job drove the number up — not call volume. In that case, look at the process-count line on the graph. A ballooning process count without a matching channel rise points to a software problem rather than a hardware limit.

flowchart TD
  A["Peak load at or above core count"] --> B{"Channel count also spiked?"}
  B -->|Yes| C["Real call surge"]
  C --> D{"Happens every shift?"}
  D -->|Yes| E["Capacity ceiling - resize or split"]
  D -->|No| F["Transient peak - monitor and tune dial level"]
  B -->|No| G{"Process count spiked?"}
  G -->|Yes| H["Runaway process or stuck job"]
  H --> I["Investigate and restart offending service"]
  G -->|No| J["IO wait or SYSTEM CPU high - check disk"]

Using peak load for capacity planning

Track the peak load figure across several consecutive busy shifts, not just one. A single afternoon that hit saturation might be an anomaly — a month of afternoons that all peak above core count is a trend. That trend is your signal to resize before the degradation becomes customer-facing. Compare shifts of similar call volume so you are not confusing a quiet Sunday with a Monday morning power hour.

The average load figure in the summary block is a complement to peak, not a replacement. Average can look healthy even when peak is alarming if most of the shift was quiet. For a full breakdown of all the metrics you should be watching shift to shift, see our guide to monitoring VICIdial server health and capacity.

For a deeper look at how load correlates with the Asterisk channel count, see how to read the Server Performance Report — particularly the section on reading the four graphs together.

Rather than sizing a box yourself, spin up a managed VICIdial box on VICIfast and get a right-sized server provisioned in under 40 seconds with performance logging enabled from the first boot.