Written by: Matt Beuchel, CEO, Plura AI
Key Takeaways
- Most VICIdial slowdowns come from four subsystems: OS and disk I/O, MySQL/MariaDB, Asterisk, or network/RTP congestion.
- Start with six intake questions and command outputs so you know which subsystem to investigate before changing any settings.
- Swap usage, MyISAM lock contention, orphaned
vicidial_auto_callsrows, and web-layer bottlenecks frequently cause agent screen lag or dialing degradation. - Archiving log tables, lowering swappiness, and moving reporting to replicas extend capacity, but single-server VICIdial still hits an architectural ceiling around 20 to 25 agents.
- When tuning no longer delivers returns, migrating to a modern platform like Plura AI removes those structural bottlenecks.
Answer Card: The Four Subsystems Behind VICIdial Slowdowns
VICIdial performance issues usually trace to under-resourced servers, untuned MySQL/MariaDB, Asterisk configuration, or network/RTP congestion. Database bloat from unarchived MyISAM log tables combined with swap usage is one of the most common causes of VICIdial performance issues. MyISAM table-level lock contention, undersized key_buffer_size, and missing indexes also appear frequently. Identify the responsible subsystem before tuning anything.
- Agent screen slow, dispositions lag: MySQL/MariaDB
- Audio robotic but screen fine: network/RTP
- Dialing degrades through the day:
vicidial_auto_callsorvicidial_hopper - Everything slow, agents frozen: swap or disk I/O
Before You Start: The Six-Question Intake
Gather this context before you run diagnostic commands:
- What VICIdial version and SVN revision are you running?
- How many concurrent agents are active?
- What are the server specs (CPU cores, RAM, storage type)?
- Is this a single server or a cluster?
- What exactly feels slow: screen, audio, dialing, or everything?
- What is the output of:
uptime,free -h,df -h,top,SHOW FULL PROCESSLIST,asterisk -rx 'core show channels count',screen -list?
Answers to questions one through five point you to the right subsystem. The outputs in question six provide the evidence you need, so capture them before you change anything.
OS-Level Checks: The Swap Death Spiral
The first OS check focuses on memory pressure. Run free -h. On a dedicated VICIdial server, any active swap usage during production hours is a danger sign, because a swapping telephony server quickly develops call latency, jitter, and dropped calls. Then run vmstat 1 5 and watch the wa column. If IO wait consistently exceeds 20%, disk I/O, not CPU, is the bottleneck.
The swap death spiral follows a documented sequence. The database server sits at 28 GB of 32 GB RAM and runs normally. Linux then swaps application memory to make room for filesystem cache. MyISAM reads compete with swap I/O, so MySQL slows. Perl daemons queue while they wait on database responses, memory spikes from the queued processes, and more swapping occurs. Within minutes, agents freeze and calls drop.
The fix is to lower swappiness so the kernel prefers dropping cache over swapping application memory. Set vm.swappiness = 10 in /etc/sysctl.d/99-vicidial.conf and apply it with sysctl --system. On a dedicated VICIdial box, you can push the value as low as 1 because no other workloads compete for memory.
Next, check disk latency. Run iostat -x 1 and review await. On SSD, it should stay under 1 ms; on HDD, under 10 ms. Values above 20 ms on SSD or 50 ms on HDD indicate the disk cannot keep up with I/O demand.
If await is elevated, run iotop -o -P to identify the process driving I/O. On VICIdial servers, MySQL activity and call-recording writes to /var/spool/asterisk/monitor/ commonly drive disk pressure and I/O wait, although failing disks can also cause high latency. Then check disk usage with df -h. Disk usage above 80% needs attention. At 90% the system enters a danger zone, and at 95% MySQL may stop accepting writes.
MySQL/MariaDB Checks: Where Most VICIdial Slowdowns Live
If OS checks look healthy, move to the database. Run SHOW FULL PROCESSLIST and look for queries in Locked state. This pattern indicates MyISAM table-level lock contention, which is the classic VICIdial database issue. A single slow SELECT on vicidial_log blocks every INSERT, UPDATE, and DELETE on that table until the SELECT finishes. Also note any queries running longer than two seconds.
Check the Slow_queries status variable. If it grows by more than one per minute, the database has a performance problem.
Review table sizes with du -sh /var/lib/mysql/asterisk/*. The tables that grow without bound include vicidial_log, vicidial_closer_log, vicidial_agent_log, call_log, and recording_log. A 50-agent center dialing 300 numbers per agent per day adds about 15,000 rows per day to vicidial_log, reaching more than 5 million rows after a year.
Reporting on the live system creates a separate risk. Heavy reporting queries against the production master can degrade live dialing performance. Operations handling more than 50,000 calls per day often move reporting to a MySQL read replica.
For ongoing control, schedule ADMIN_archive_log_tables.pl --daily in cron at 1 AM to move old records into _archive tables. High-volume systems often keep only the last 24 hours in hot tables. Common retention windows are 90 days for vicidial_log and related log tables, and 7 days for vicidial_manager.
Also confirm that skip-name-resolve is set in my.cnf. Without this setting, MySQL performs a reverse DNS lookup on every connection. In a cluster, telephony servers, web servers, and cron jobs all hit the database, and those lookups can create a backlog that resembles a “too many connections” issue, even when raising max_connections does not help.
Asterisk and Channel Checks: Carrier Problem or Dialer Problem?
Channel counts show whether the dialer is placing calls. Run asterisk -rx 'core show channels count' and compare active channels to your expected concurrent calls. If channels stay flat while agents sit idle, the dialer is not sending calls, so check the hopper next.
Then validate carrier health. Run asterisk -rx 'sip show peers' or asterisk -rx 'pjsip show endpoints'. If peers show UNREACHABLE or LAGGED, the carrier or trunk path is responsible.
Use the channel count and agent reports together. If core show channels count shows active channels but agents report no audio, the issue sits in network or RTP. If channels are zero while agents remain in READY status, the dialer or hopper is at fault.
Roughly 80% of VICIdial no-audio or one-way-audio incidents trace to a firewall blocking UDP ports 10000-20000 (RTP), 15% to a missing externip in sip.conf, and 5% to SIP ALG on a NAT router.3 Check these network items before changing Asterisk configuration.
The Slow Web Interface With Clear Media Fork
This diagnostic fork separates web and database issues from media issues. If the agent screen is slow but calls are perfectly clear, the bottleneck sits on the agent-screen web path, usually the agent network or workstation, or the web or database server layer, rather than RTP. This pattern appears in the vicidial.org thread “slow web interface (http) but perfectly clear media (rtp)” and works well as a structured diagnostic step.
Start with server load. Run top and check Apache or PHP-FPM CPU usage. If web processes are pegged, the web layer is the problem. Then run SHOW FULL PROCESSLIST and look for queries originating from the web server IP.
If media stays clear while the screen lags, focus on the database or web server instead of Asterisk or RTP. Each Apache + mod_php process with VICIdial uses 30 to 60 MB of RAM. At 500 concurrent agents, the web server alone can consume 15 to 30 GB of RAM. Nginx with PHP-FPM can handle the same connections with far less memory.
Ready to stop tuning and start scaling? See the AI Predictive Dialer handle high-volume outbound traffic and compare it against your current web-layer performance.
Stale vicidial_auto_calls and Dead astguiclient Screen Processes
Dialing that slows down over time often points to orphaned dialer records. Run this query to detect them:
SELECT auto_call_id, server_ip, campaign_id, status, call_time, TIMESTAMPDIFF(MINUTE, call_time, NOW()) AS minutes_old FROM vicidial_auto_calls WHERE call_time < NOW() - INTERVAL 30 MINUTE;
Clean them up with:
DELETE FROM vicidial_auto_calls WHERE call_time < NOW() - INTERVAL 30 MINUTE;
Next, confirm that dialer daemons are alive. Run screen -list. The expected VICIdial screen sessions include AST_update, AST_send_listen, AST_VDauto_dial, and FastAGI_log. Missing sessions indicate dialer degradation. The ADMIN_keepalive_ALL.pl script, scheduled in cron every minute, detects and restarts missing screen sessions.
VICIdial keepalive scripts run once per minute, so a dead screen session can cause up to 60 seconds of dialer downtime. At 500 agents and a 3:1 dial ratio, that can mean roughly 1,500 calls not placed and about 500 agents sitting idle.
Verify critical processes with this command:
ps aux | grep -E "AST_|ADMIN_|VD" | grep -v grep
A healthy VICIdial installation shows 8 to 12 background AST_ processes, so a lower count signals that a daemon has died. If AST_VDauto_dial or AST_VDadapt are missing, outbound dialing stops or dial ratios freeze.
When Tuning Stops Working: The Honest Ceiling
Tuning extends VICIdial capacity, but three structural limits define the ceiling.
First, single-server MySQL contention. VICIdial does not cluster its database. The primary database runs as a single instance, and Asterisk and MySQL share the same CPU, RAM, and disk I/O on a single-server deployment. A read replica can offload reporting, but it adds cost and operational complexity.
Second, reporting on live systems. VICIdial’s database access pattern mixes high-frequency writes with constant polling from agent screens. It also runs transactional and analytical workloads on a single, non-clusterable MySQL instance. A supervisor who runs a campaign report at 10 AM can lock the dialer for the duration of that SELECT.
Third, the operational cost of maintaining the stack. A VICIdial system administrator needs skills across Linux administration, Asterisk telephony, MySQL/MariaDB, and VICIdial configuration, and sources commonly cite full-time salaries between $55,000 and $120,000 per year.3
A single all-in-one VICIdial server typically tops out around 20 to 25 agents for predictive outbound dialing.3 Asterisk’s architecture, not the hardware, sets this ceiling. Michael Cargile, Director of Engineering at The VICIdial Group, stated: “The biggest limiting factor is Asterisk itself. It has locking issues. Throwing monstrously powerful servers at it does not help.”4
When archiving, MEMORY tables, and read replicas have delivered all the headroom they can, migration becomes the practical path forward. The next section explains what that move looks like for high-volume operations.
Conclusion: When Tuning Stops Paying
VICIdial performance issues concentrate in four subsystems, and the diagnostic playbook above helps you pinpoint the responsible layer quickly. OS swap and I/O wait, MySQL lock contention and table bloat, Asterisk channel and process state, and the web or database fork from the media layer each have clear commands and thresholds that guide your next step.
Tuning still has a ceiling. Single-server MySQL contention, reporting on live systems, and the operational cost of maintaining the stack mean that beyond roughly 25 outbound agents, many operations look at migration. Archiving, MEMORY tables, and read replicas extend runway, but Asterisk and MySQL still share a single database instance.
Plura AI’s AI Predictive Dialer is a Vici Dial replacement built for high-volume teams that have reached this ceiling. Plura runs voice, SMS, RCS, and webchat conversations on 100% U.S. infrastructure, and it is FCC-licensed.2 The AI Predictive Dialer uses stateful conversion signals to decide who to call next, and calls travel over Plura’s carrier with branded caller ID and STIR/SHAKEN authentication.1 Plura owns its carrier stack rather than wrapping a third-party CPaaS, and it supports compliance for regulated operators.2
Watch the AI Predictive Dialer run at scale, or compare plans and rates side by side on the Plura pricing page.
1 Plura AI maintains SOC 2, HIPAA, ISO, and GDPR posture as part of its platform infrastructure. References to compliance frameworks in this article describe Plura’s platform capabilities and do not constitute a guarantee that any customer using Plura will themselves be compliant with applicable laws or standards. Customers remain solely responsible for their own regulatory obligations, certifications, consent management, recordkeeping, and the claims they make to their own end users. Consult qualified legal counsel for guidance specific to your use case.
2 This article describes regulatory frameworks at a general level and does not constitute legal advice. Laws and regulations vary by jurisdiction, change over time, and apply differently depending on facts and circumstances. Readers should consult qualified legal counsel before making compliance decisions.
3 Performance figures, customer outcomes, and industry statistics referenced in this article are drawn from cited third-party sources or Plura customer case studies. Individual results vary based on implementation, use case, industry, audience, and execution. Past or aggregate performance is not a guarantee of future results.
4 References to third-party products, services, companies, or research are made for informational and comparative purposes only. Plura AI is not affiliated with, endorsed by, or sponsored by any third party named in this article unless explicitly stated. Trademarks and product names referenced remain the property of their respective owners.
This article is provided for informational purposes only and reflects Plura AI’s understanding at the time of publication. Product capabilities, integrations, and specifications are subject to change. For the most current information, visit plura.ai.
This article was produced with the assistance of AI tools and reviewed by Plura AI prior to publication.