vicidial.org

Hi!
At more than about 120 agents logged in I've encountered an issue with my web server logs showing mysql_connect errors and no matter what I did to the MySQL server variables, web server variables or ulimit settings, this error remained.

I found that there were massive amounts (20000+) of TIME_WAIT states to the database server showing using "netstat -n". This indicates that the web server is running out of available resources (sockets?) to connect to the database. After some research I found that setting /proc/sys/net/ipv4/tcp_tw_recycle from 0 to 1 reduces the number of TIME_WAIT instances and thereby removing any mysql_connect errors. I'm not certain this is the proper way to fix this but it has done the trick.

There is also the tcp_tw_reuse option that should do the same but I'm not certain yet.

I'm curious as to whether anyone else has seen this sort of thing and if I might have introduced a bigger problem into this system by using these options? I am running Vicibox ISO install with OpenSUSE on the web server, stats below.

Vincent.

--
Version: 2.6-372a BUILD: 120713-2123
Load: 0.03 0.06 0.02
Servers: DB: CentOS 6.2, Web+Dialers OpenSuse Vicibox 3.1.15
HW: DB: Dual Xeon Hex E5630@ .53GHz 32GB RAM, Dialerx4: Xeon Quad X5355@2.66GHz 8GB RAM, Web: Dual Xeon Quad E5420@2.50GHz 16GB RAM
Codecs: ulaw on soft-phones / g729 to carrier.
VoIP, no direct PSTN

Please remember to always post your Vicidial Version with Build. The rest of your specs are excellent and well detailed, but the Vici Version with Build is always the most important inforamation to remember to post.

You also did not report the results of this change ... I am assuming that this resolved your problem, but I note that while you shared the "technical" description of the problem (server log entries), you did not share whether this problem manifested itself in any problems with agents and whether your solution resolved that problem.

Good post, though!

Hi,

The problem manifested itself as mysql_connect errors on the web server and mysql_connect errors on the real-time and agent screens. The fix resulted in far less TIME_WAIT connections and no errors in the log or front end.
Is this not the build number in the footer? Version: 2.6-372a BUILD: 120713-2123

--
Vin

Is this not the build number in the footer? Version: 2.6-372a BUILD: 120713-2123

so it is! lol (you must have typed it too quickly because I read right past it).

You likely need to modify your mysql configuration to allow for a high-density server suitable for Vicidial.

you could consider installing a "db only" server in a VM to get those settings, or search this forum for them as they have been discussed many times in the past.

Vicidial uses a lot (some say too many, but then again it WORKS) of connections. You may be running out. There are of course other settings as well.

Look for posts by Kumba and Matt that deal with mysql in high-volume scenarios.

Thanks williamconley.
The DB server is indeed dedicated on a decent LSI RAID 10 SAS controller. There appear to be no bottlenecks on any of the hardware and reporting does come from a dedicated replication slave.
I check MySQL connection counts and tested all possible tuning variables especially wait and connection time-outs.

This is solved anyhow but I will endeavour to push as the limits of the system as I can.
--
Vin

do consider a vmware installation or finding a posted sample of my.cnf for high volume mysql machines. just good mysql is not the point, the point is good VICIDIAL proven settings for mysql.

Same here, after yesterday's update to VERSION: 2.8-417a BUILD: 131019-0849 I'm having multiple records like this:
131104 16:59:43 [Warning] Aborted connection 1102 to db: 'asterisk' user: 'cron' host: '192.168.9.21' (Unknown error)
131104 16:59:45 [Warning] Aborted connection 1835 to db: 'asterisk' user: 'cron' host: '192.168.9.22' (Unknown error)
131104 16:59:47 [Warning] Aborted connection 3824 to db: 'asterisk' user: 'cron' host: '192.168.9.15' (Unknown error)
6 Asterisk servers, 1 web server and dedicated DB. It took us a while to find out that we are having 26k of ports with TIME_WAIT to DB. Around 100 agents logged in, nearly half dialing, 200-300 calls total, all that stuff is making 2.5-2.7k mysql requests per second.
After changing tcp_tw_recycle busy ports look like this:
voip13:~ # netstat -an | grep TIME_WAIT | grep 3306 | wc -l
84
voip13:~ # netstat -an | grep TIME_WAIT | grep 3306 | wc -l
104
voip13:~ # netstat -an | grep TIME_WAIT | grep 3306 | wc -l
174
Bump for a useful thread since it took use several hours of heavy debug to find the reason.

PierreDeux wrote:Same here, after yesterday's update to VERSION: 2.8-417a BUILD: 131019-0849 I'm having multiple records like this:
131104 16:59:43 [Warning] Aborted connection 1102 to db: 'asterisk' user: 'cron' host: '192.168.9.21' (Unknown error)
131104 16:59:45 [Warning] Aborted connection 1835 to db: 'asterisk' user: 'cron' host: '192.168.9.22' (Unknown error)
131104 16:59:47 [Warning] Aborted connection 3824 to db: 'asterisk' user: 'cron' host: '192.168.9.15' (Unknown error)
6 Asterisk servers, 1 web server and dedicated DB. It took us a while to find out that we are having 26k of ports with TIME_WAIT to DB. Around 100 agents logged in, nearly half dialing, 200-300 calls total, all that stuff is making 2.5-2.7k mysql requests per second.
After changing tcp_tw_recycle busy ports look like this:
voip13:~ # netstat -an | grep TIME_WAIT | grep 3306 | wc -l
84
voip13:~ # netstat -an | grep TIME_WAIT | grep 3306 | wc -l
104
voip13:~ # netstat -an | grep TIME_WAIT | grep 3306 | wc -l
174
Bump for a useful thread since it took use several hours of heavy debug to find the reason.

1) Welcome to the Party!

2) As you are obviously new here, I have some suggestions to help us all help you:

You should post your installation method (link to the instructions if they are online, the name of the .iso image of the install disks, and any actions performed outside the .iso install and/or any special actions taken during the install or configuration settings changed).

Similar to This:

Vicibox X.X from .iso | Vicidial X.X.X-XXX Build XXXXXX-XXXX | Asterisk X.X.X | Single Server | No Digium/Sangoma Hardware | No Extra Software After Installation | Intel DG35EC | Core2Quad Q6600

3) As you are dropping deep technical results without any background ... you may want to consider cluing us in on the effect this has on your system. Me, too, usually turns out to be not entirely true on forums. So quoting the actual error or condition is helpful before the "me, too".

4) As you have a large system, do you have the large system database configuration in place? (Kumba's install CD will enact large database settings upon request during database install ...)

williamconley wrote:

PierreDeux wrote:Same here, after yesterday's update to VERSION: 2.8-417a BUILD: 131019-0849 I'm having multiple records like this:
131104 16:59:43 [Warning] Aborted connection 1102 to db: 'asterisk' user: 'cron' host: '192.168.9.21' (Unknown error)
131104 16:59:45 [Warning] Aborted connection 1835 to db: 'asterisk' user: 'cron' host: '192.168.9.22' (Unknown error)
131104 16:59:47 [Warning] Aborted connection 3824 to db: 'asterisk' user: 'cron' host: '192.168.9.15' (Unknown error)
6 Asterisk servers, 1 web server and dedicated DB. It took us a while to find out that we are having 26k of ports with TIME_WAIT to DB. Around 100 agents logged in, nearly half dialing, 200-300 calls total, all that stuff is making 2.5-2.7k mysql requests per second.
After changing tcp_tw_recycle busy ports look like this:
voip13:~ # netstat -an | grep TIME_WAIT | grep 3306 | wc -l
84
voip13:~ # netstat -an | grep TIME_WAIT | grep 3306 | wc -l
104
voip13:~ # netstat -an | grep TIME_WAIT | grep 3306 | wc -l
174
Bump for a useful thread since it took use several hours of heavy debug to find the reason.

1) Welcome to the Party!

2) As you are obviously new here, I have some suggestions to help us all help you:

You should post your installation method (link to the instructions if they are online, the name of the .iso image of the install disks, and any actions performed outside the .iso install and/or any special actions taken during the install or configuration settings changed).

Similar to This:

Vicibox X.X from .iso | Vicidial X.X.X-XXX Build XXXXXX-XXXX | Asterisk X.X.X | Single Server | No Digium/Sangoma Hardware | No Extra Software After Installation | Intel DG35EC | Core2Quad Q6600

3) As you are dropping deep technical results without any background ... you may want to consider cluing us in on the effect this has on your system. Me, too, usually turns out to be not entirely true on forums. So quoting the actual error or condition is helpful before the "me, too".

4) As you have a large system, do you have the large system database configuration in place? (Kumba's install CD will enact large database settings upon request during database install ...)

2. I'm not new here. It's Vicibox 5.0.3
3. What am I dropping?
4. Sure thing I have a large dedicated DB server. Dual Quad/Hexa/Octo-Core E5-2600 Sandy Bridge Romley Xeons
96GB DDR3 Ram
240 GB Intel Solid State Drive 520 series * 2 (for db)
1000GB SATAIII * 2 (for fast daily backups)
Raid 1 for each pair of drives.
Centos 6

DB stress test with sysbench showed no problems: we created a test 1m records table and updated it in 400 flows with 200k of queries - not a single problem. However when we set "reconnect after each request" option to yes we are getting those aborted errors.
Experiments with tcp_tw_recycle (manuals say, that it can break some software) showed that it stopped apache from accepting new connections, some users were able to log in, however most had timeout error. Replacing it with tcp_tw_reuse (which is less aggressive) improved the things, however we are still experiencing the DB issue with aborted connections.
Here is my.cnf:

Code: Select all

 [mysqld]
max_allowed_packet=128M
skip-name-resolve
log-warnings=2
table_cache = 20480
myisam_sort_buffer_size = 256M
default-storage-engine=MyISAM
skip-innodb

bulk_insert_buffer_size=256M

datadir=/data/mysql
socket=/data/mysql/mysql.sock
tmpdir=/home/tmp/
user=mysql
bind-address=192.168.9.253
max_connections=800
old_passwords=0
open_files_limit=64270

log-slow-queries = /var/log/mysql-slow-queries.log
long_query_time = 5

key_buffer_size = 41G

query_cache_size = 20G

thread_cache_size = 32
query_cache_limit = 64M
join_buffer_size = 32M
sort_buffer_size = 16M
read_rnd_buffer_size = 2M
max_heap_table_size=12G
tmp_table_size=256M

connect_timeout=60
wait_timeout=600
thread_concurrency=24

concurrent_insert=2

The problem is even more complicated cuz we are not getting those "abort" errors constantly: sometimes tests run smooth (with reconnect enabled) and sometimes not. I can't find any dependence that could cause the fault

Update:
Seems I can't repeat any "abort" errors with mysql tests anymore, looks like they appeared due to another reason, that took place at the moment of testing.

That certainly does not appear to be a "stock" 5.0.3 my.cnf file.

Have you considered reverting to stock to see if this problem goes away (while it may cause others ... you may solve this one).

And then look for the "Enterprise" my.cnf settings that Vicibox will install if you tell it to be a dedicated heavy load db server for a vicidial cluster?

I have not read the entire post again, but do not see in your remarks what the "symptom" is that you are fighting. Dialer stops dialing? Can't log in to a web page? Or is this just a chase down the error in the log exercise?

Sure thing it's not a stock mysql config, cuz the stock one does not preform good on my load. Just for fun I've tried my-bigvici.cnf that comes with vicibox - it did not change anything.
As for the reason I have already posted some logs:

Same here, after yesterday's update to VERSION: 2.8-417a BUILD: 131019-0849 I'm having multiple records like this:
131104 16:59:43 [Warning] Aborted connection 1102 to db: 'asterisk' user: 'cron' host: '192.168.9.21' (Unknown error)
131104 16:59:45 [Warning] Aborted connection 1835 to db: 'asterisk' user: 'cron' host: '192.168.9.22' (Unknown error)
131104 16:59:47 [Warning] Aborted connection 3824 to db: 'asterisk' user: 'cron' host: '192.168.9.15' (Unknown error)

Connections are getting randomly aborted. This comes from all servers in my cluser and I can't find any reason for that.

I've noticed 2 more issues (most probably everything is connected with each other):
1. Amount of calls constantly varies no matter what dial method (adapt or ratio) is set or how many free agents there are. There can be 20 calls, than 100 calls, than back to 20 in one minute or even less. It's highly unstable.
2. When there are many calls waiting for agents (e.g. I've seen many times issues like 30 calls are waiting for 5-10 seconds while there are 40 free agents) I'm getting a lot of those aborts in DB logs. However most of those calls seem to connect to agents.
I can't find anything about mysql errors in any logs on my web or dialers. Not in /var/log/astguiclient, no anywhere else. That's weird.

131104 16:59:45 [Warning] Aborted connection 1835 to db: 'asterisk' user: 'cron' host: '192.168.9.22' (Unknown error)

This does not tell me anything about your symptom. I doubt your problem is that you don't want this line to be in that file because it takes up too much room on the hard drive. I suspect you are talking about problems with the dialer (which you still haven't mentioned, but in your next post you are getting closer!)

1. Amount of calls constantly varies no matter what dial method (adapt or ratio) is set or how many free agents there are. There can be 20 calls, than 100 calls, than back to 20 in one minute or even less. It's highly unstable.

The system that generates the amount of calls has very specific reasons for doing so. There is a constantly running script that monitors the system and makes the decisions of what should be dialed now. Access that script (it is one of the many screens available via "screen -list") and you can find out why this behavior occurs and trace that problem, likely to an unrelated process. Unrelated meaning "nothing to do with mysql having an error".

2. When there are many calls waiting for agents (e.g. I've seen many times issues like 30 calls are waiting for 5-10 seconds while there are 40 free agents) I'm getting a lot of those aborts in DB logs. However most of those calls seem to connect to agents.

And based on your comments, you are saying that these aborts happened in the stock vicidial mysql configuration as well? Or "it had problems" not specifically THIS problem?

I can't find anything about mysql errors in any logs on my web or dialers. Not in /var/log/astguiclient, no anywhere else. That's weird.

Unless these aborts are due to processes that abandoned the mysql thread and mysql responded by aborting the "already being ignored" thread. This is why i wanted to find the symptom and see if we can attack from that direction instead.

Unless you can find a connection that was aborted (trace it back to an originating process), you could spend a long time trying to figure out why.

This does not tell me anything about your symptom. I doubt your problem is that you don't want this line to be in that file because it takes up too much room on the hard drive. I suspect you are talking about problems with the dialer (which you still haven't mentioned, but in your next post you are getting closer!)

Well, again: I'm getting a lot of aborted connection to vicidial db. I can't find anything about that on any of my web or dialer server's logs, however a lot of such aborts can be seen from DB's side. Further investigation showed that those aborts are caused by connections not properly closed. On top of that I've noticed, that vicidial makes several requests (I've seen 84 myself) in a single connection. Here is the example of aborted request:

Code: Select all

1340666 Connect cron@192.168.9.15 as anonymous on asterisk
                1340666 Query   set autocommit=1
                1340666 Query   SELECT agi_output,local_gmt FROM servers where server_ip = 'X.X.X.X' (one of my IP addresses was here)
                1340666 Query   SELECT enable_queuemetrics_logging,queuemetrics_server_ip,queuemetrics_dbname,queuemetrics_login,queuemetrics_pass,queuemetrics_log_id,queuemetrics_eq_prepend,queuemetrics_pe_phone_append,did_agent_log,alt_log_server_ip,alt_log_dbname,alt_log_login,alt_log_pass,tables_use_alt_log_db,did_ra_extensions_enabled,queuemetrics_socket,queuemetrics_socket_url FROM system_settings
                1340666 Query   SELECT call_handle_method,agent_search_method,group_id,did_pattern,list_id,phone_code,campaign_id,user,user_unavailable_action,user_route_settings_ingroup,did_route,voicemail_ext,extension,exten_context,phone,server_ip FROM vicidial_inbound_dids where did_id = '126'
                1340666 Query   SELECT voicemail_dump_exten,ext_context,answer_transfer_agent,local_gmt,asterisk_version,max_vicidial_trunks FROM servers where server_ip = '68.233.253.217'
                1340666 Query   UPDATE vicidial_inbound_groups SET group_calldate='2013-11-07 08:48:38' where group_id='English'
                1340666 Query   SELECT call_time_id,after_hours_action,after_hours_message_filename,after_hours_exten,after_hours_voicemail,welcome_message_filename,moh_context,onhold_prompt_filename,prompt_interval,agent_alert_exten,agent_alert_delay,drop_call_seconds,drop_action,drop_exten,next_agent_call,voicemail_ext,queue_priority,drop_inbound_group,afterhours_xfer_group,play_place_in_line,play_estimate_hold_time,hold_time_option,hold_time_option_seconds,hold_time_option_exten,hold_time_option_voicemail,hold_time_option_xfer_group,hold_time_option_callback_filename,hold_time_option_callback_list_id,hold_recall_xfer_group,no_delay_call_route,play_welcome_message,no_agent_no_queue,no_agent_action,no_agent_action_value,extension_appended_cidname,uniqueid_status_display,uniqueid_status_prefix,hold_time_option_minimum,hold_time_option_press_filename,hold_time_option_callmenu,onhold_prompt_no_block,onhold_prompt_seconds,hold_time_option_no_block,hold_time_option_prompt_seconds,hold_time_second_option,hold_time_third_option,wait_hold_option_priority,wait_time_option,wait_time_second_option,wait_time_third_option,wait_time_option_seconds,wait_time_option_exten,wait_time_option_voicemail,wait_time_option_xfer_group,wait_time_option_callmenu,wait_time_option_callback_filename,wait_time_option_callback_list_id,wait_time_option_press_filename,wait_time_option_no_block,wait_time_option_prompt_seconds,active,calculate_estimated_hold_seconds,add_lead_url,eht_minimum_prompt_filename,eht_minimum_prompt_no_block,eht_minimum_prompt_seconds,on_hook_ring_time,ingroup_recording_override,ingroup_rec_filename,on_hook_cid,action_xfer_cid,drop_callmenu,after_hours_callmenu,max_calls_method,max_calls_count,max_calls_action FROM vicidial_inbound_groups where group_id = 'English'
                1340666 Query   SELECT ct_default_start,ct_default_stop,default_afterhours_filename_override ,ct_thursday_start,ct_thursday_stop,thursday_afterhours_filename_override ,ct_wednesday_start,ct_wednesday_stop,ct_holidays FROM vicidial_call_times where call_time_id = '24hours'
                1340666 Query   SELECT lead_id from vicidial_list where phone_number='4073017666'  order by last_local_call_time desc limit 1

Increasing mysql timeouts did not help:

Code: Select all

| interactive_timeout                   | 28800             |
| net_read_timeout                      | 60                |
| net_write_timeout                     | 120               |
| wait_timeout                          | 28800             |

Those aborted connections actually perform their requests (that's why I have no errors on client side), however do not close the connection properly.

The system that generates the amount of calls has very specific reasons for doing so. There is a constantly running script that monitors the system and makes the decisions of what should be dialed now. Access that script (it is one of the many screens available via "screen -list") and you can find out why this behavior occurs and trace that problem, likely to an unrelated process. Unrelated meaning "nothing to do with mysql having an error".

Thx for the suggestion, I've checked vdauto screen and it does not contain anything suspicious (errors, warnings or whatever). Here is the example of campaign debug while it's placing less calls, than it should place:

Code: Select all

---------- ADAPT DEBUG

Campaign Debug: route72 - Route72 US           2013-11-07 10:59:13

Total leads in hopper right now:             1106

Adapt Debug:     2013-11-07 10:59:05
     route72 hopper READY count:   1073
     route72 agents LOGGED-IN count:   66
0     |route72|5|1073|9am-9pm|15|60|
     TIME CALL CHECK: 13838396451383839941
CAMPAIGN DIFFERENTIAL: 66.2   23.1333333333333   (23.1333333333333 - 0)
     CAMPAIGN ANSWERED STATUSES: route72|DROP,XDROP,CALLBK,CBHOLD,DEC,SALE,NI,NP,XFER,RQXFER,TIMEOT,AFTHRS,NANQUE,DropM,SALEFP,411,QCFAIL|
route72|1.20|2.47|     |185  7491  2129|   0
     LIVE CALLS: 102|SELECT count(*) from vicidial_auto_calls where campaign_id=route72
     AGENT TIME STATS: 46021 511247 85401 89752|SELECT sum(pause_sec),sum(wait_sec),sum(talk_sec) - sum(dead_sec) as custtalk,sum(dispo_sec) + sum(dead_sec) as acw from vicidial_agent_log where event_time > 2013-11-07 00:00:01 and campaign_id=route72 and pause_sec < 65000 and wait_sec < 65000 and talk_sec < 65000 and dispo_sec < 65000 and dead_sec < 65000
     AGENT CALLS: 5257|SELECT count(*) from vicidial_agent_log where event_time > 2013-11-07 00:00:01 and campaign_id=route72 and lead_id > 0


CAMPAIGN:   route72     0
SETTINGS-
   DIAL LEVEL:    2
   DIAL METHOD:   ADAPT_AVERAGE
   AVAIL ONLY:    N
   DROP PERCENT:  48
   MAX LEVEL:     2
   SERVER TIME:   1059
   LATE TARGET:   2100     (1041 left|1)
   INTENSITY:     30
   DLDIFF TARGET: 3
CURRENT STATS-
   AVG AGENTS:      66.85
   AGENTS:          66  ACTIVE: 48   CALC: 48  INCALL: 25    READY: 23
   DL DIFFERENTIAL: 21.25 = (18.25 + 3)
DIAL LEVEL SUGGESTION-
      PERCENT DIFF: 31.79
      SUGGEST DL:   2.636 = (2 * (0.317875841436051 + 1) )
      INTENSE DIFF: 41.32
      INTENSE DL:   2.826 = (2 * (0.413238593866866 + 1) )
      DIAL LEVEL OVER CAP! SETTING TO CAP: 2
DROP STATS-
   TODAY DROPS:     7491   185   2.47%
     ANSWER DROPS:     2129   8.69%
   ONE HOUR DROPS:  4487/1229   52   1.16%
   HALF HOUR DROPS: 2333/653   19   0.81%
   FIVE MIN DROPS:  333/86   4   1.20%
   ONE MIN DROPS:   36/6   2   5.56%
DIAL LEVEL UPDATED TO: 2          CONFIRM: 1

X.X.X.28 Debug:     2013-11-07 10:59:01
ROUTE72 X.X.X.28: agents: 4 (READY: 1)    dial_level: 2     (1|0|1)   3
ROUTE72 X.X.X.28: Calls to place: 6 (8 - 2 [0 + 2|5|0]) 14
CAMPAIGN DIFFERENTIAL: 26.7   8.4   (8.5 - 0.1)
LOCAL TRUNK SHORTAGE: 0|0  (14 - 300)


X.X.X.30 Debug:     2013-11-07 10:59:01
ROUTE72 X.X.X.30: agents: 6 (READY: 1)    dial_level: 2     (1|2|4)   3
ROUTE72 X.X.X.30: Calls to place: -12 (12 - 24 [0 + 24|5|0]) 34
CAMPAIGN DIFFERENTIAL: 23.2   6.15   (8 - 1.85)
LOCAL TRUNK SHORTAGE: 0|0  (22 - 300)


X.X.X.31 Debug:     2013-11-07 10:59:01
ROUTE72 X.X.X.31: agents: 7 (READY: 2)    dial_level: 2     (2|2|0)   3
ROUTE72 X.X.X.31: Calls to place: 6 (14 - 8 [0 + 8|5|0]) 14
CAMPAIGN DIFFERENTIAL: 67.3   16.55   (18.9 - 2.35)
LOCAL TRUNK SHORTAGE: 0|0  (14 - 300)


X.X.X.32 Debug:     2013-11-07 10:59:01
ROUTE72 X.X.X.32: agents: 19 (READY: 7)    dial_level: 2     (7|9|0)   3
ROUTE72 X.X.X.32: Calls to place: 4 (38 - 34 [0 + 34|5|0]) 38
CAMPAIGN DIFFERENTIAL: 67.25   16.3   (18.55 - 2.25)
LOCAL TRUNK SHORTAGE: 0|0  (38 - 300)


X.X.X.33 Debug:     2013-11-07 10:59:01
ROUTE72 X.X.X.33: agents: 3 (READY: 0)    dial_level: 2     (0|0|1)   3
ROUTE72 X.X.X.33: Calls to place: 4 (6 - 2 [0 + 2|5|0]) 6
CAMPAIGN DIFFERENTIAL: 67.1   16.1   (18.75 - 2.65)
LOCAL TRUNK SHORTAGE: 0|0  (6 - 300)


X.X.X.34 Debug:     2013-11-07 10:59:01
ROUTE72 X.X.X.34: agents: 12 (READY: 6)    dial_level: 2     (6|3|2)   3
ROUTE72 X.X.X.34: Calls to place: 17 (24 - 7 [0 + 7|4|0]) 26
CAMPAIGN DIFFERENTIAL: 66.85   18.25   (19.15 - 0.9)
LOCAL TRUNK SHORTAGE: 0|0  (26 - 300)


X.X.X.35 Debug:     2013-11-07 10:59:01
ROUTE72 X.X.X.35: agents: 12 (READY: 4)    dial_level: 2     (4|5|0)   3
ROUTE72 X.X.X.35: Calls to place: 1 (24 - 23 [0 + 23|5|0]) 25
CAMPAIGN DIFFERENTIAL: 67.35   16.8   (18.55 - 1.75)
LOCAL TRUNK SHORTAGE: 0|0  (25 - 300)


Inbound Debug: English    2013-11-07 10:58:42
     ANSWERED STATUSES: English|DROP,XDROP,CALLBK,CBHOLD,DEC,SALE,NI,NP,XFER,RQXFER,TIMEOT,AFTHRS,NANQUE,DropM,SALEFP,411,QCFAIL|
     DAILY STATS|4|70|0|11         IN-GROUP: English   CALLS: 1082   ANSWER: 1004   DROPS: 49
               Stat1: 978   Stat2: 995   Hold: 4413.50|2019.75|833.00

Dial level on my real time screen always shows the maximum allowed in the campaign settings, however seems that it has no connection to what is really dialed there. I've also checked asterisk and DB at this moment - no errors or stuck requests there too.

And based on your comments, you are saying that these aborts happened in the stock vicidial mysql configuration as well? Or "it had problems" not specifically THIS problem?

Yes, it has aborts on the default config too. Stock config was slow I've tried it some time ago.

what I have already tried with campaign settings:
1. Changed dial methods to all adapt ones and ratio
2. Tried different dial levels
3. Tried both "Dial Level Difference Target Methods"
4. Dial Level Difference Target (setting it to X calls waiting for agents)
5. Adapt Intensity Modifier (setting it +30)
All this does not affect on the number of placed calls.

PierreDeux,
Please post your real time stats including carrier stats, after running in automode for some time.

Vin.