VICIdial system load explained

System load is the number operators glance at most and understand least. On a VICIdial box it shows up in the performance summary as an average and a peak, and a single misread can send you chasing the wrong problem. Here is what it actually measures and how to judge it.

What load actually counts

System load is the average number of processes that were either running or waiting their turn to run. A load of 1.0 means, on average, exactly one process was always wanting the CPU. The catch is that the number only makes sense next to your core count. On a four-core box a load of 4.0 means every core is fully occupied with nothing queued — busy, but fine. On a single-core box that same 4.0 means three processes are stuck waiting for every one that runs.

The rule of thumb: divide load by your number of cores. Below 1.0 per core, the box has headroom. Around 1.0 per core, it is saturated but coping. Well above 1.0 per core and processes are queuing, which on a dialer shows up as slow screen pops, late hangups and dropped audio.

Average versus peak

The performance summary gives you both an average system load and a peak system load for the shift. Average is your steady state — if that is high, the box is undersized for the work. Peak is the worst instant in the window. A high peak with a low average usually points to a brief event: a list reset, a snapshot job, or a flood of Concurrent calls hitting at once. A high average is the one that means you need more machine.

Load is not CPU percentage

This trips up a lot of people. CPU at 100 percent with a load equal to your core count is a fully used, healthy box. But load can climb high while CPU sits low — that happens when processes are blocked waiting on disk or network rather than the processor. On a VICIdial server this often means database queries piling up or recording writes stalling. So always read load next to the USER, SYSTEM and IDLE CPU split, not on its own.

flowchart TD
  A["System load high?"] --> B{"CPU IDLE near zero?"}
  B -->|Yes| C["CPU bound"]
  C --> D["Add cores or cut dial level"]
  B -->|No| E{"Load high but CPU idle?"}
  E -->|Yes| F["Processes blocked on disk or DB"]
  F --> G["Check recordings disk and slow queries"]
  E -->|No| H["Box is busy but healthy"]

What pushes load up on a dialer

The biggest lever is how aggressively you dial. Every line your Predictive dialing engine opens spins up an audio path and the Channel handling that goes with it, so cranking the dial ratio raises load directly. Background work adds to it too: the Keepalive processes that keep VICIdial's services alive, call recording, and reporting queries all want CPU. When load climbs, easing Dialer pacing back a notch is usually faster than adding hardware.

Note: a load number that briefly spikes during a nightly maintenance job is normal and not worth chasing. Only a sustained high average across a working shift means the box is genuinely under-provisioned.

Load is just one figure in a fuller view of the server. To see where it sits among off-hook minutes, channel counts and the CPU split, walk through how to read the Server Performance Report, and for the overall routine see our pillar on monitoring VICIdial server health and capacity.

Don't want to size a box by hand? VICIfast ships a right-sized, load-monitored VICIdial server live in under 40 seconds, so the load number stays in the green from day one.