How to read the Server Performance Report graphs

The graph section of the Server Performance Report plots four metrics over the same time window, and the real diagnostic value comes from looking at them together — each series alone tells you part of a story, but the correlations between them reveal what is actually happening on the box.

The four series and what they show

Data is sampled every five seconds, so the graph captures even short spikes that a one-minute average would smooth away. The four lines plotted are:

• Number of processes — the total count of running and sleeping processes on the OS at each sample. A steady climb here without a matching channel rise points to a software problem rather than call volume.
• System load — the run-queue depth (load average), a direct signal of CPU demand. Compare the peaks here against your box's core count to judge saturation.
• Number of Asterisk channels — live audio legs at each moment. Every bridged call occupies at least two Channel entries. This line tracks real call activity.
• USER and SYSTEM processor percentages — the CPU split over time. USER is application work, SYSTEM is kernel overhead. The IDLE fraction is implied: 100 % minus these two.

How to read them together across a shift

The standard way to work through the graph is left to right, looking for moments where two or more lines deviate from their typical relationship. Four common patterns cover most situations:

• Load and channels rise together — a real call surge. The box is doing proportionally more audio work. If load stays under core count and USER dominates the CPU split, the hardware is coping.
• Load spikes but channels stay flat — a runaway process or a stuck job. Look at the process-count line: if it climbs at the same time, something is forking too many child processes or a keepalive loop is spinning.
• SYSTEM CPU rises independently of USER — kernel overhead increasing without matching application work. This often means disk I/O pressure from Call recording files or excessive network interrupts from a misconfigured carrier.
• All four lines stay low across the whole shift — the box has spare capacity; consider whether you can run more agents or raise the Dial level before the next busy day.

flowchart TD
  A["Load spike on graph"] --> B{"Channels up too?"}
  B -->|Yes| C["Real call surge"]
  C --> D{"Load above core count?"}
  D -->|Yes| E["Capacity ceiling - resize or lower dial level"]
  D -->|No| F["Healthy surge - box coping"]
  B -->|No| G{"Process count up?"}
  G -->|Yes| H["Runaway process - check keepalives"]
  G -->|No| I{"SYSTEM CPU high?"}
  I -->|Yes| J["Disk IO or network interrupt pressure"]
  I -->|No| K["Transient anomaly - monitor next shift"]

Spotting shift transitions in the graph

The graph is particularly useful for seeing the shape of a shift. A well-managed dialer operation typically shows channels and load rising as agents log in, plateauing through the main calling window, and dropping cleanly as the shift ends. If you see load staying high after channels drop at end of shift, that is a signal that Asterisk has zombie channels or a background job that did not terminate. The process count line usually confirms it — look for a count that does not fall back to the baseline level.

This report also covers the Real-time report blind spot — the real-time view only shows the current moment, while the performance graphs let you compare this Tuesday afternoon against last Tuesday afternoon to see whether the trend is moving in the right direction.

For a broader framework covering which metrics to track across shifts and what action thresholds to set, the guide to monitoring VICIdial server health and capacity is the right starting point.

For the system load line specifically — what the number means and how to compare it against your core count — see VICIdial system load explained.

If you would rather not deal with server sizing at all, spin up a managed VICIdial box on VICIfast — it provisions in under 40 seconds with performance logging on from boot, so your first graph data appears within minutes of going live.