If your "vicidial_list" table is HUGE, it can take an inordinate amount of time to be optimized. During the time that this table is being optimized, nothing that involves any leads can progress. The same of course applies to all log tables.
Even something as seemingly simple as an inbound call is not really "simple". It's made to look/seem simple by all the programming that went into Vicidial. An inbound call must first be identified by the DID upon which it arrived, then the route for the call is determined, and in most cases a lead is either created or 'looked up'. Depending on the route of the call, it may also hit the call menu table and the ingroup tables. Each stage is also logged for reporting purposes. Even the timing of the various stages (time in queue, hold time, etc) is logged in a table. All these tables are optimized and any one of them being locked during optimization will cause a delay that lasts longer than Asterisk can wait for a resolution.
To mitigate this:
1) Prune your vicidial_list table. Try to keep it under 5M records. 10M if you have a very powerful DB server. Note that you CAN just push these leads into a different table or even a different database instead of deleting them. We have a module for this, but any MySQL person should be able to move records from one table to another. Note that once you move vicidial_list records out of that table, those records will no longer be reportable. Run reports before moving them, or be prepared to bring them back to run reports.
2) Archive all logs. Keep only 30-60 days of live logs. Archive the rest.
There are scripts in /usr/share/astguiclient for log archiving. In most installs there's a commented out entry in crontab -e. You can still run reports on archived log data, but you need to check the archived checkbox on the report.
Note that in both cases, your improvement will NOT be notable until AFTER the Next Time optimization occurs after pruning/archiving. (ie: prune/archive ... optimize will show benefits AFTER the optimize has completed. Not during, not before. After.) But: After that, the process will be significantly improved and (if you've archived enough) not interrupt calling much at all during future optimizations. Only for a few seconds per table if you're lucky.
Happy Hunting!
: