Asterisk high CPU during calls does not automatically mean your phone server needs more processors. Codec conversion, recording, custom scripts, and repeated dialplan actions can each increase work. Storage delays can also raise system load without using much CPU.
The useful question is narrower: which activity grows when calls begin, and which process performs that work? Start with matching timestamps, channel counts, and process measurements. Then test one suspected cause without disrupting normal calling.
Define the Call Pattern Before Changing Anything
Record when the problem starts and what callers experience. Note distorted audio, delayed answers, failed transfers, or an unresponsive administration screen. These symptoms may share a cause, but they do not prove processor exhaustion.
- Does usage rise with every call or only certain routes?
- Does the spike begin during ringing, after answer, or after hangup?
- Do recorded calls behave differently from approved unrecorded test calls?
- Did a codec, trunk, integration, or recording setting recently change?
- Does CPU usage return to normal when calls end?
Collect a quiet baseline and a busy sample using the same tools. Include the time zone and sample duration. Avoid comparing a brief spike against an unrelated daily average.
Do not start with a restart, broad debug logging, or a live load test. Those actions can erase evidence or worsen an overloaded system. Agree on a maintenance window and rollback plan before changing call handling.
Confirm Which Process Uses the CPU
Separate Asterisk high CPU from general server load. A database, backup task, recording converter, or integration worker may compete with the phone service.
The following inspection commands require appropriate access. Replace PID with the verified Asterisk process ID. Tool availability and options vary by Linux distribution.
pgrep -a asterisk
ps -eo pid,ppid,comm,%cpu,%mem --sort=-%cpu
top -H -p PID
pidstat -u -d -p PID 1 10
vmstat 1 10Use top to observe current activity; press q to exit. Its thread view shows individual execution threads within Asterisk. A single busy thread can limit performance even when other processors remain idle.
The ps CPU figure reflects a process lifetime average, not the same interval as a live sample. Also check each tool’s CPU scale. Some report 100 percent per logical processor.
High user CPU suggests application work. High system CPU points toward kernel work. I/O wait indicates waiting for storage, while steal time suggests host contention on a virtual server. Neither alone proves Asterisk needs more CPU capacity.
Match Asterisk CPU Usage to Channel Counts
A channel represents one call leg, not necessarily one complete conversation. A simple bridged call commonly has two channels. Transfers, queues, and internal Local channels can create more.
Run brief snapshots through the Asterisk command-line interface:
asterisk -rx 'core show channels count'
asterisk -rx 'core show channels concise'
asterisk -rx 'core show channel CHANNEL_NAME'Replace CHANNEL_NAME with a name from the channel listing. Protect the output because it may contain phone numbers and routing details. Consult the official Asterisk documentation for your installed branch and available commands.
Record active channels alongside CPU at matching times. Compare calls of the same type. Ten simple calls and ten recorded conference calls do not represent equal workloads.
If channels remain after users hang up, inspect their applications, durations, and destinations. Long-lived channels can be legitimate, so do not terminate them blindly. Repeated creation and removal may reveal retries or an integration loop.
Asterisk high CPU with few channels deserves special attention. One looping call path or expensive media operation can outweigh many ordinary calls.
Inspect Codec Conversion and the Media Path
A codec encodes voice for transport. Transcoding converts audio between codecs and adds processing work. A trunk and phone using different codecs may force Asterisk to perform that conversion.
Inspect the active channel’s read and write formats, native formats, and translation details where available. Configuration lists show permitted codecs, not necessarily the formats an active call uses.
- Compare both call legs rather than one endpoint.
- Check whether affected calls use a different codec pair.
- Note conference mixing, recording, or other audio processing.
- Compare CPU during calls with matching negotiated codecs.
core show translation can help explain available translation paths and their costs. It is not a live counter of current transcoding sessions. Avoid recalculating translation benchmarks during an overloaded production period.
Matching codecs does not guarantee that audio bypasses Asterisk. Bridge behavior and enabled features affect the media path. Our guide to tracing the call audio path explains that distinction.
Do not enable direct media solely to reduce CPU. First verify recording, network address translation, security, and feature requirements. A lighter processor load is not useful if calls lose audio.
Separate Recording Work From Disk Delays
Recording can involve audio mixing, file writes, format conversion, and post-call processing. These tasks may run inside Asterisk or in separate programs.
Check when the spike occurs. During-call growth suggests active recording or media work. A burst after hangup may point toward compression, uploads, transcription, or a recording hook.
iostat -xz 1 10
pidstat -d -p PID 1 10
df -h
df -iThese tools may require additional packages. Arrange installation through normal change control rather than adding software during an incident. Review interval samples; some tools first display averages since boot.
Look for rising storage latency, queued requests, and matching process writes. Free space alone does not prove storage performs well. Network-mounted recording storage and shared virtual disks need separate checks.
Disk utilization figures also need context, especially on parallel storage. Correlate them with latency and call symptoms rather than treating one percentage as a universal limit.
Use approved test calls to compare recording paths. Never disable required recording or delete recordings just to test a theory.
Check AGI, ARI, and Dialplan Repetition
The dialplan defines how Asterisk handles calls. AGI, the Asterisk Gateway Interface, connects call handling to external programs. ARI, the Asterisk REST Interface, lets applications control channels and media.
AGI scripts can consume CPU in separate processes. ARI applications may run elsewhere while generating repeated requests against Asterisk. Check both the phone server and the integration host.
- Inspect child processes and repeated script launches.
- Match application request rates to channel creation.
- Check external service timeouts and retry limits.
- Look for repeated channel, bridge, or playback operations.
A slow external request may stall a call without causing high CPU. Conversely, rapid retries can create heavy work. Distinguish waiting from repeated execution before changing timeout values.
Inspect the dialplan path for repeated Goto, While, or recursive subroutine calls without a valid exit. Correlate repeated application steps with one channel identifier.
In FreePBX, use supported configuration methods and custom extension points. Direct edits to generated dialplan files may disappear during configuration updates. Test corrected logic on a controlled route before exposing normal calls.
Keep Diagnostic Logging From Becoming the Problem
Verbose console output, protocol traces, and repeated warnings can increase CPU and disk activity. Logging may amplify an existing fault rather than cause the original problem.
Review current logging destinations and verbosity first. Use logger show channels where available. Prefer a short, targeted capture over broad logging across every call.
Record previous settings before enabling a trace. Set a stop time, monitor storage, and restore the original settings afterward. Call signaling and application logs can reveal personal information or credentials.
If warnings repeat rapidly, identify the failing operation behind them. Simply hiding those messages can make the server quieter while leaving the loop intact.
Validate the Cause With a Controlled Comparison
Close an Asterisk high CPU investigation with evidence, not just a lower dashboard number. Change one factor and repeat a comparable test at similar channel counts.
- Codec hypothesis: compare negotiated formats and CPU per similar call.
- Recording hypothesis: compare approved recording paths and storage latency.
- Integration hypothesis: compare request rates, worker activity, and channel churn.
- Dialplan hypothesis: confirm repeated execution stops and normal routing still works.
Check audio in both directions, transfers, hangup cleanup, and required recordings. Save before-and-after measurements with the change and rollback details. Escalate unexplained hot threads with timestamps, software versions, channel snapshots, and bounded logs. Invasive profiling needs specialist planning because it can interrupt service.
If the cause spans media handling, custom code, and storage, professional remote assistance may be appropriate. Tech Rescue Ops LLC offers remote VoIP and PBX support to review evidence and plan controlled tests without treating a restart as the diagnosis.