Safe CPU and load thresholds for a VICIdial box

A VICIdial server reports its CPU breakdown and system load every five seconds. The numbers are there, but they are only useful if you know what ranges are healthy. This post gives you practical thresholds so you know when to keep watching and when to act.

Load average and your core count

The system load figure is an exponential moving average of how many processes are in the run queue — waiting for a CPU core — measured over 1, 5, and 15 minutes. The rule of thumb that holds across Linux systems is simple: load should stay at or below your CPU core count during normal operations. On a 4-core VPS, a load of 4 means every core is occupied but nothing is waiting. A load of 8 on that same box means work is stacking up faster than the cores can drain it.

For a VICIdial dialer specifically, the practical comfortable range is load at 60 to 80 percent of your core count during peak hours, with room to spike briefly above core count during predictive bursts. Sustained load at double your core count or higher for more than a few minutes is a clear problem. The Server Performance Report shows both average load and peak load per shift so you can spot which hours are chronically over threshold.

CPU breakdown: USER, SYSTEM, and IDLE

The processor time split tells you where the CPU is spending its cycles. USER percentage is the work your application processes are doing: Asterisk bridging audio, PHP serving agent screens, Perl running Keepalive and dialing scripts. SYSTEM percentage is kernel and operating system work: network interrupts, disk I/O handling, and context switching. IDLE is the unused headroom.

• IDLE above 20 percent during peak dialing — healthy, you have headroom.
• IDLE between 5 and 20 percent — the box is busy; watch for trends but not an emergency.
• IDLE below 5 percent sustained — no slack left; any burst work will queue behind everything else.
• SYSTEM above 30 percent of total — look at disk I/O and network interrupt rates; this is not application load, it is infrastructure pressure.

Reading load against channels

Load numbers only make sense when you look at them alongside Concurrent calls and Channel count. High load with rising channel count is a real call surge — reduce the dial level or plan a resize. High load with flat channel count means something other than call traffic is consuming CPU: a stuck database query, a runaway process, or a log-writing loop. The two-graph view in the Server Performance Report is designed for exactly this correlation.

flowchart LR
  A["Load above core count"] --> B{"Channels rising?"}
  B -->|Yes| C["Call surge — lower dial-level or resize"]
  B -->|No| D{"SYSTEM CPU high?"}
  D -->|Yes| E["Disk / network pressure"]
  D -->|No| F{"Process count up?"}
  F -->|Yes| G["Runaway process — identify and restart"]
  F -->|No| H["Investigate DB query backlog"]

Thresholds by common server sizes

A 2-core entry box running a small inbound Ingroup with 10 to 20 Agent seats should stay comfortably under load 2 during peak hours. A 4-core box running a blended predictive campaign with 30 to 50 agents will typically run between load 2 and 3.5 during dialing peaks. An 8-core box running 80 or more agents on aggressive predictive dialing should stay under load 6 at peak and recover to under load 2 between shifts. If your box regularly peaks above those numbers, the next step is to check whether load correlates with call volume or whether it is something else.

For the full picture of what each metric represents and how to track it over time, see the server health and capacity guide. For a closer look at how these thresholds show up in the performance graphs, how to read server performance graphs walks through the chart view in detail.

On a Single tenant managed host, you have dedicated cores for your call traffic — no noisy neighbours inflating your load numbers. See what a right-sized box costs on the VICIfast pricing page.