What high system load actually means on a dialer

When a VICIdial operator sees a high system load number, the instinct is often to restart Asterisk or reduce the dial level. Sometimes that is exactly right, but sometimes the call traffic is fine and something else entirely is driving the load. Understanding what system load actually measures — and what it does not — lets you pick the correct response.

What the load average number actually measures

Linux system load is the average length of the CPU run queue: how many threads are either executing on a core or waiting in line for one, averaged over 1, 5, and 15 minutes. A load of 1 on a single-core machine means one thread is always busy or waiting. The same load of 1 on an 8-core machine means the box is barely ticking over. This is why you always read load relative to core count, not as an absolute number.

A VPS with 8 cores at load 8 is fully occupied but not backed up — every core is busy and no work is waiting. That same box at load 16 has a serious problem: one unit of work is completing while another sits in line. Calls that need to be bridged, Agent screens that need to update, and Keepalive scripts checking process health all compete on that same queue.

High USER CPU versus high SYSTEM CPU

Load average tells you work is piling up but not why. The CPU breakdown answers the why. USER percentage is Asterisk handling audio, PHP rendering pages, Perl running dialing scripts. Rising USER means call processing work is genuinely heavy. SYSTEM percentage is the kernel layer: network interrupt handling, disk I/O, and process context switching. Rising SYSTEM with flat USER usually points at disk writes — often Call recording files being written at scale — or network handling for high Concurrent calls volumes.

A box where USER is 60 percent, SYSTEM is 10 percent, and IDLE is 30 percent is doing genuine call work with comfortable headroom. A box where USER is 20 percent, SYSTEM is 70 percent, and IDLE is 10 percent is dealing with a kernel-level bottleneck — check disk activity and network interrupt rates rather than reducing your dial level.

Rising load with channels versus without

The most useful diagnostic on a VICIdial box is comparing load to Channel count. Each active call leg opens a channel on Asterisk. If load is rising and channel count is rising with it, you are dealing with a real surge in call volume — the box is working harder because there is genuinely more work. The correct response is to reduce the dial level or plan a resize. If load is rising but channel count is flat, something other than calls is consuming CPU. The most common culprits on a dialer are a database query that will not finish, a stuck log-rotation process, or an ad-hoc report running during peak hours.

flowchart TD
  A["Load above core count"] --> B{"Channel count rising?"}
  B -->|Yes| C["Real call surge"]
  C --> D{"IDLE below 10%?"}
  D -->|Yes| E["Reduce dial level or resize"]
  D -->|No| F["Monitor — burst may be brief"]
  B -->|No| G{"SYSTEM CPU high?"}
  G -->|Yes| H["Disk or network bottleneck"]
  G -->|No| I["Runaway process or slow DB query"]

What a runaway process looks like

A stuck or looping process drives load without producing useful work. On a VICIdial box the usual suspects are a Perl keepalive script that has entered a tight retry loop, a PHP session handler writing to disk faster than it can flush, or a MySQL query that has locked a table and is blocking dozens of subsequent queries. The Server Performance Report will show load rising and process count rising together while channel count stays flat — that pattern is a strong signal to check the process list rather than the campaign settings.

For a broader framework of what to watch and how often, start with the server health and capacity guide. For more on interpreting the USER/SYSTEM/IDLE split in context, read VICIdial CPU: USER, SYSTEM, and IDLE explained.

On a Single tenant box with dedicated cores, load numbers reflect your workload alone. If you want a sized, monitored dialer without the infrastructure guesswork, see what a VICIfast managed box costs.