{"id":3751,"date":"2026-09-12T05:04:14","date_gmt":"2026-09-12T05:04:14","guid":{"rendered":"https:\/\/www.plura.ai\/articles\/vicidial-performance-issues"},"modified":"2026-09-12T05:04:14","modified_gmt":"2026-09-12T05:04:14","slug":"vicidial-performance-issues","status":"publish","type":"post","link":"https:\/\/www.plura.ai\/articles\/vicidial-performance-issues","title":{"rendered":"VICIdial Slowdowns: Diagnose All Four Subsystems"},"content":{"rendered":"<p><em>Written by: Matt Beuchel, CEO, Plura AI<\/em><\/p>\n<h2 id=\"key-takeaways\">Key Takeaways<\/h2>\n<ul>\n<li>Most VICIdial slowdowns come from four subsystems: OS and disk I\/O, MySQL\/MariaDB, Asterisk, or network\/RTP congestion.<\/li>\n<li>Start with six intake questions and command outputs so you know which subsystem to investigate before changing any settings.<\/li>\n<li>Swap usage, MyISAM lock contention, orphaned <code>vicidial_auto_calls<\/code> rows, and web-layer bottlenecks frequently cause agent screen lag or dialing degradation.<\/li>\n<li>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.<\/li>\n<li>When tuning no longer delivers returns, migrating to a modern platform like <a href=\"https:\/\/www.plura.ai\/plura-webchat\" target=\"_blank\">Plura AI<\/a> removes those structural bottlenecks.<\/li>\n<\/ul>\n<h2>Answer Card: The Four Subsystems Behind VICIdial Slowdowns<\/h2>\n<p>VICIdial performance issues usually trace to under-resourced servers, untuned MySQL\/MariaDB, Asterisk configuration, or network\/RTP congestion. <a href=\"https:\/\/flixzone.icu\/tutorials\/vicidial-database-performance-optimization\/\" target=\"_blank\" rel=\"noindex nofollow\">Database bloat from unarchived MyISAM log tables combined with swap usage is one of the most common causes of VICIdial performance issues<\/a>. MyISAM table-level lock contention, undersized <code>key_buffer_size<\/code>, and missing indexes also appear frequently. Identify the responsible subsystem before tuning anything.<\/p>\n<ul>\n<li>Agent screen slow, dispositions lag: MySQL\/MariaDB<\/li>\n<li>Audio robotic but screen fine: network\/RTP<\/li>\n<li>Dialing degrades through the day: <code>vicidial_auto_calls<\/code> or <code>vicidial_hopper<\/code><\/li>\n<li>Everything slow, agents frozen: swap or disk I\/O<\/li>\n<\/ul>\n<h2>Before You Start: The Six-Question Intake<\/h2>\n<p>Gather this context before you run diagnostic commands:<\/p>\n<ol>\n<li>What VICIdial version and SVN revision are you running?<\/li>\n<li>How many concurrent agents are active?<\/li>\n<li>What are the server specs (CPU cores, RAM, storage type)?<\/li>\n<li>Is this a single server or a cluster?<\/li>\n<li>What exactly feels slow: screen, audio, dialing, or everything?<\/li>\n<li>What is the output of: <code>uptime<\/code>, <code>free -h<\/code>, <code>df -h<\/code>, <code>top<\/code>, <code>SHOW FULL PROCESSLIST<\/code>, <code>asterisk -rx 'core show channels count'<\/code>, <code>screen -list<\/code>?<\/li>\n<\/ol>\n<p>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.<\/p>\n<h2>OS-Level Checks: The Swap Death Spiral<\/h2>\n<p>The first OS check focuses on memory pressure. Run <code>free -h<\/code>. <a href=\"https:\/\/kingasterisk.com\/vicidial-system-lag-fix-slow-dialer-2026\/\" target=\"_blank\" rel=\"noindex nofollow\">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.<\/a> Then run <code>vmstat 1 5<\/code> and watch the <code>wa<\/code> column. If IO wait consistently exceeds 20%, disk I\/O, not CPU, is the bottleneck.<\/p>\n<p>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.<\/p>\n<p>The fix is to lower swappiness so the kernel prefers dropping cache over swapping application memory. Set <code>vm.swappiness = 10<\/code> in <code>\/etc\/sysctl.d\/99-vicidial.conf<\/code> and apply it with <code>sysctl --system<\/code>. On a dedicated VICIdial box, you can push the value as low as 1 because no other workloads compete for memory.<\/p>\n<p>Next, check disk latency. Run <code>iostat -x 1<\/code> and review <code>await<\/code>. <a href=\"https:\/\/intramweb.com\/server-performance\/disk-io-bottleneck-linux\" target=\"_blank\" rel=\"noindex nofollow\">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.<\/a><\/p>\n<p>If <code>await<\/code> is elevated, run <code>iotop -o -P<\/code> to identify the process driving I\/O. <a href=\"https:\/\/vicidial.org\/VICIDIALforum\/viewtopic.php?t=24390\" target=\"_blank\" rel=\"noindex nofollow\">On VICIdial servers, MySQL activity and call-recording writes to <code>\/var\/spool\/asterisk\/monitor\/<\/code> commonly drive disk pressure and I\/O wait, although failing disks can also cause high latency.<\/a> Then check disk usage with <code>df -h<\/code>. Disk usage above 80% needs attention. At 90% the system enters a danger zone, and at 95% MySQL may stop accepting writes.<\/p>\n<h2>MySQL\/MariaDB Checks: Where Most VICIdial Slowdowns Live<\/h2>\n<p>If OS checks look healthy, move to the database. Run <code>SHOW FULL PROCESSLIST<\/code> and look for queries in <code>Locked<\/code> state. This pattern indicates MyISAM table-level lock contention, which is the classic VICIdial database issue. A single slow SELECT on <code>vicidial_log<\/code> blocks every INSERT, UPDATE, and DELETE on that table until the SELECT finishes. Also note any queries running longer than two seconds.<\/p>\n<p>Check the <code>Slow_queries<\/code> status variable. If it grows by more than one per minute, the database has a performance problem.<\/p>\n<p>Review table sizes with <code>du -sh \/var\/lib\/mysql\/asterisk\/*<\/code>. The tables that grow without bound include <code>vicidial_log<\/code>, <code>vicidial_closer_log<\/code>, <code>vicidial_agent_log<\/code>, <code>call_log<\/code>, and <code>recording_log<\/code>. A 50-agent center dialing 300 numbers per agent per day adds about 15,000 rows per day to <code>vicidial_log<\/code>, reaching more than 5 million rows after a year.<\/p>\n<p>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.<\/p>\n<p>For ongoing control, schedule <code>ADMIN_archive_log_tables.pl --daily<\/code> in cron at 1 AM to move old records into <code>_archive<\/code> tables. High-volume systems often keep only the last 24 hours in hot tables. Common retention windows are 90 days for <code>vicidial_log<\/code> and related log tables, and 7 days for <code>vicidial_manager<\/code>.<\/p>\n<p>Also confirm that <code>skip-name-resolve<\/code> is set in <code>my.cnf<\/code>. 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 \u201ctoo many connections\u201d issue, even when raising <code>max_connections<\/code> does not help.<\/p>\n<h2>Asterisk and Channel Checks: Carrier Problem or Dialer Problem?<\/h2>\n<p>Channel counts show whether the dialer is placing calls. Run <code>asterisk -rx 'core show channels count'<\/code> 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.<\/p>\n<p>Then validate carrier health. Run <code>asterisk -rx 'sip show peers'<\/code> or <code>asterisk -rx 'pjsip show endpoints'<\/code>. If peers show <code>UNREACHABLE<\/code> or <code>LAGGED<\/code>, the carrier or trunk path is responsible.<\/p>\n<p>Use the channel count and agent reports together. If <code>core show channels count<\/code> 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.<\/p>\n<p>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 <code>externip<\/code> in sip.conf, and 5% to SIP ALG on a NAT router.<sup data-disclaimer-id=\"24\" data-disclaimer-index=\"3\">3<\/sup> Check these network items before changing Asterisk configuration.<\/p>\n<h2>The Slow Web Interface With Clear Media Fork<\/h2>\n<p>This diagnostic fork separates web and database issues from media issues. <a href=\"https:\/\/vicifast.com\/blog\/fix-agent-screen-frozen\" target=\"_blank\" rel=\"noindex nofollow\">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.<\/a> This pattern appears in the <a href=\"https:\/\/vicidial.org\" target=\"_blank\" rel=\"noindex nofollow\">vicidial.org<\/a> thread \u201cslow web interface (http) but perfectly clear media (rtp)\u201d and works well as a structured diagnostic step.<\/p>\n<p>Start with server load. Run <code>top<\/code> and check Apache or PHP-FPM CPU usage. If web processes are pegged, the web layer is the problem. Then run <code>SHOW FULL PROCESSLIST<\/code> and look for queries originating from the web server IP.<\/p>\n<p>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.<\/p>\n<p><strong>Ready to stop tuning and start scaling?<\/strong> <a href=\"https:\/\/plura.ai\/ai-predictive-dialer\" target=\"_blank\" rel=\"noindex nofollow\">See the AI Predictive Dialer handle high-volume outbound traffic<\/a> and compare it against your current web-layer performance.<\/p>\n<figure style=\"text-align: center\"><img decoding=\"async\" src=\"https:\/\/cdn.aigrowthmarketer.co\/1779338793506-2d33c5dff8e8.png\" alt=\"Plura Predictive Dialer dashboard displaying AI-powered outbound call pacing, transfer analysis, and dialing performance insights.\" style=\"max-height: 500px\" loading=\"lazy\"><figcaption><em>Plura Predictive Dialer automates outbound calling with AI-powered pacing, transfer optimization, and real-time performance analytics.<\/em><\/figcaption><\/figure>\n<h2>Stale vicidial_auto_calls and Dead astguiclient Screen Processes<\/h2>\n<p>Dialing that slows down over time often points to orphaned dialer records. Run this query to detect them:<\/p>\n<p><code>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 &lt; NOW() - INTERVAL 30 MINUTE;<\/code><\/p>\n<p><a href=\"https:\/\/flixzone.icu\/tutorials\/vicidial-troubleshooting-mega-guide\" target=\"_blank\" rel=\"noindex nofollow\">Any entry older than 30 minutes is orphaned. These stale rows make the predictive dialer believe lines are still in use, which creates phantom queue depth and \u201cno live calls waiting\u201d even when agents sit in READY status.<\/a><\/p>\n<p>Clean them up with:<\/p>\n<p><code>DELETE FROM vicidial_auto_calls WHERE call_time &lt; NOW() - INTERVAL 30 MINUTE;<\/code><\/p>\n<p><a href=\"https:\/\/flixzone.icu\/tutorials\/vicidial-troubleshooting-mega-guide\" target=\"_blank\" rel=\"noindex nofollow\">If orphaned rows keep appearing, widen the <code>uniqueid<\/code> column to VARCHAR(40) on <code>vicidial_auto_calls<\/code>, <code>vicidial_log<\/code>, and <code>call_log<\/code>.<\/a><\/p>\n<p>Next, confirm that dialer daemons are alive. Run <code>screen -list<\/code>. <a href=\"https:\/\/flixzone.icu\/tutorials\/vicidial-cluster-setup-guide\" target=\"_blank\" rel=\"noindex nofollow\">The expected VICIdial screen sessions include <code>AST_update<\/code>, <code>AST_send_listen<\/code>, <code>AST_VDauto_dial<\/code>, and <code>FastAGI_log<\/code>. Missing sessions indicate dialer degradation. The <code>ADMIN_keepalive_ALL.pl<\/code> script, scheduled in cron every minute, detects and restarts missing screen sessions.<\/a><\/p>\n<p>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.<\/p>\n<p>Verify critical processes with this command:<\/p>\n<p><code>ps aux | grep -E \"AST_|ADMIN_|VD\" | grep -v grep<\/code><\/p>\n<p>A healthy VICIdial installation shows 8 to 12 background <code>AST_<\/code> processes, so a lower count signals that a daemon has died. If <code>AST_VDauto_dial<\/code> or <code>AST_VDadapt<\/code> are missing, outbound dialing stops or dial ratios freeze.<\/p>\n<h2>When Tuning Stops Working: The Honest Ceiling<\/h2>\n<p>Tuning extends VICIdial capacity, but three structural limits define the ceiling.<\/p>\n<p>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.<\/p>\n<p>Second, reporting on live systems. VICIdial\u2019s 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.<\/p>\n<p>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.<sup data-disclaimer-id=\"24\" data-disclaimer-index=\"3\">3<\/sup><\/p>\n<p>A single all-in-one VICIdial server typically tops out around 20 to 25 agents for predictive outbound dialing.<sup data-disclaimer-id=\"24\" data-disclaimer-index=\"3\">3<\/sup> Asterisk\u2019s architecture, not the hardware, sets this ceiling. Michael Cargile, Director of Engineering at The VICIdial Group, stated: \u201cThe biggest limiting factor is Asterisk itself. It has locking issues. Throwing monstrously powerful servers at it does not help.\u201d<sup data-disclaimer-id=\"25\" data-disclaimer-index=\"4\">4<\/sup><\/p>\n<p>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.<\/p>\n<h2>Conclusion: When Tuning Stops Paying<\/h2>\n<p>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.<\/p>\n<p>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.<\/p>\n<p>Plura AI\u2019s <a href=\"https:\/\/plura.ai\/ai-predictive-dialer\" target=\"_blank\" rel=\"noindex nofollow\">AI Predictive Dialer<\/a> is a <a href=\"https:\/\/plura.ai\/compare\" target=\"_blank\" rel=\"noindex nofollow\">Vici Dial replacement<\/a> 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.<sup data-disclaimer-id=\"23\" data-disclaimer-index=\"2\">2<\/sup> The AI Predictive Dialer uses stateful conversion signals to decide who to call next, and calls travel over Plura\u2019s carrier with branded caller ID and STIR\/SHAKEN authentication.<sup data-disclaimer-id=\"22\" data-disclaimer-index=\"1\">1<\/sup> Plura owns its carrier stack rather than wrapping a third-party CPaaS, and it supports compliance for regulated operators.<sup data-disclaimer-id=\"23\" data-disclaimer-index=\"2\">2<\/sup><\/p>\n<p><a href=\"https:\/\/plura.ai\/ai-predictive-dialer\" target=\"_blank\" rel=\"noindex nofollow\">Watch the AI Predictive Dialer run at scale<\/a>, or compare plans and rates side by side on the <a href=\"https:\/\/plura.ai\/pricing\" target=\"_blank\">Plura pricing page<\/a>.<\/p>\n<hr data-disclaimer-divider=\"true\">\n<div data-disclaimer-footer=\"true\">\n<p data-disclaimer-id=\"22\" data-disclaimer-type=\"content_based\"><sup data-disclaimer-index=\"1\">1<\/sup> 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\u2019s 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.<\/p>\n<p data-disclaimer-id=\"23\" data-disclaimer-type=\"content_based\"><sup data-disclaimer-index=\"2\">2<\/sup> 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.<\/p>\n<p data-disclaimer-id=\"24\" data-disclaimer-type=\"content_based\"><sup data-disclaimer-index=\"3\">3<\/sup> 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.<\/p>\n<p data-disclaimer-id=\"25\" data-disclaimer-type=\"content_based\"><sup data-disclaimer-index=\"4\">4<\/sup> 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.<\/p>\n<p data-disclaimer-id=\"21\" data-disclaimer-type=\"fixed\">This article is provided for informational purposes only and reflects Plura AI\u2019s understanding at the time of publication. Product capabilities, integrations, and specifications are subject to change. For the most current information, visit plura.ai.<\/p>\n<p data-disclaimer-id=\"27\" data-disclaimer-type=\"fixed\">This article was produced with the assistance of AI tools and reviewed by Plura AI prior to publication.<\/p>\n<\/div>\n<section data-read-next=\"true\">\n<h2>Read Next<\/h2>\n<ul>\n<li><a href=\"https:\/\/www.plura.ai\/articles\/vicidial-speed-to-lead\" target=\"_blank\">VICIdial Speed To Lead: Configure, Measure, and Decide<\/a><\/li>\n<li><a href=\"https:\/\/www.plura.ai\/articles\/best-vicidial-agent-attrition-fixes\" target=\"_blank\">VICIdial Agent Attrition: A Configuration Playbook<\/a><\/li>\n<li><a href=\"https:\/\/www.plura.ai\/articles\/how-to-replace-vicidial\" target=\"_blank\">How to Replace VICIdial: Step-by-Step Migration Guide (2026)<\/a><\/li>\n<li><a href=\"https:\/\/www.plura.ai\/articles\/vicidial-alternatives-2026\" target=\"_blank\">Best VICIdial Alternatives in 2026 for Contact Centers<\/a><\/li>\n<li><a href=\"https:\/\/www.plura.ai\/articles\/best-vicidial-alternatives-self-hosted\" target=\"_blank\">Best VICIdial Alternatives for Self-Hosted Dialers in 2026<\/a><\/li>\n<\/ul>\n<\/section>\n","protected":false},"excerpt":{"rendered":"<p>Stop guessing when VICIdial slows down. Plura AI helps contact center teams isolate OS, MySQL, Asterisk, and web layer issues in one structured guide.<\/p>\n","protected":false},"author":106,"featured_media":3750,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[2],"tags":[],"class_list":["post-3751","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai-contact-centers"],"_links":{"self":[{"href":"https:\/\/www.plura.ai\/articles\/wp-json\/wp\/v2\/posts\/3751","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.plura.ai\/articles\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.plura.ai\/articles\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/www.plura.ai\/articles\/wp-json\/wp\/v2\/comments?post=3751"}],"version-history":[{"count":0,"href":"https:\/\/www.plura.ai\/articles\/wp-json\/wp\/v2\/posts\/3751\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.plura.ai\/articles\/wp-json\/wp\/v2\/media\/3750"}],"wp:attachment":[{"href":"https:\/\/www.plura.ai\/articles\/wp-json\/wp\/v2\/media?parent=3751"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.plura.ai\/articles\/wp-json\/wp\/v2\/categories?post=3751"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.plura.ai\/articles\/wp-json\/wp\/v2\/tags?post=3751"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}