vicidial.org

Hi Vicidial Team,

I have this issue when this cron scripts runs:

### optimize the database tables within the asterisk database
3 1 * * * /usr/share/astguiclient/AST_DB_optimize.pl

### reset several temporary-info tables in the database
2 1 * * * /usr/share/astguiclient/AST_reset_mysql_vars.pl

our DID was unreachable, like having busy tone or hearing only dead air for at least 15mins(where I guess the length of the cron script running). I think our SIP should not be affected since the scripts our focus only in database maintenance and even if this runs we should able to hear our IVR message.

and also when this script runs asterisk cli showing this weird output bunch of them :

WARNING[48409]: chan_sip.c:4058 __sip_autodestruct: Autodestruct on dialog '3ae7eb658b8-0247-4017@10.109.0.2' with owner SIP/globe_sip-000265cf in place (Method: BYE). Rescheduling destruction for 10000 ms

ohh our system runs in
ViciBox Redux v.6.0.4
VERSION: 2.12-550a
BUILD: 160414-1013
Asterisk 1.8.32.3-vici

Thank you and looking forward for your answer

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!

Well that make sense now, our Vicidial_list table is over 18m now. will archived this lead for better performance, Thank you very much Sir William