High server load on Goautodial-3.0

[urmi.l]

Hello,

GOautodial CE 3.0 ISO | VERSION: 2.4-364a BUILD: 120409-1136 | Asterisk 1.4.39.1-vici.go | Single Server - CentOS release 5.5 | No Digium/Sangoma Hardware | No Extra Software After Installation

1) Auto Outbound , No Inbound
2) 8 to 10 Agents Only
3) Dial Level : 3 to 6
4) G729 Codec
5) Dialing Country : USA

I have dual core system and my load average goes beyond 1.0. some time it goes beyond 3 - 4 as well. I want to increase my agents but due to high load avg, I cant increase the agents.
Bellow is my setup :

Campaign Settings :

Dial Method: RATIO
Dial Timeout: 28
Available Only Tally: Y
Available Only Tally Threshold: DISABLE
Drop Percentage Limit:0
Dial Level Difference Target: 0
Adapt Intensity Modifier: 0

[root@localhost ~]# cat /proc/cpuinfo

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU 3040 @ 1.86GHz
stepping : 2
cpu MHz : 1596.000
cache size : 2048 KB

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU 3040 @ 1.86GHz
stepping : 2
cpu MHz : 1596.000
cache size : 2048 KB

[root@localhost ~]# cat /proc/meminfo | grep Mem

MemTotal: 8179000 kB
MemFree: 7144868 kB

I have a setup in which around 30 agents working fine with the same server setup on goautodial-2.1.
But in my new setup I m using Goautodial 3.0 version. Will it work properly with my dual core system ? Or do I need higher system ? Why the server load goes high with just 8 - 10 agents ? Please kindly give your suggestions for the same.

Thanks.

[williamconley]

probably because you are dialing 6:1 with g729. Do you do this on the other system?

Is your other server with 30 agents also 1.8Ghz?

Just to be clear: You say "same server setup" which is not quite the same as "same hardware" ... are you saying the hardware is identical, or ... ?

I would recommend a Core2Quad and not using g729 if you can avoid it. Also, are you recording all calls?

[urmi.l]

Just to be clear: You say "same server setup" which is not quite the same as "same hardware" ... are you saying the hardware is identical, or ... ?

Yes, same server with identical hardware.

I would recommend a Core2Quad and not using g729 if you can avoid it. Also, are you recording all calls?

I m using g729. You mean to say I should not use g729 with this hardware setup ? please guide me.

And yes I m recording all the calls.

[williamconley]

g729 is a CPU EATER. LOL. Uses very heavy load. Any channel that does not require g729 should avoid it if your cpu usage is heavy. For instance: if agent phones are local, use ulaw for them. If you have a "manual dial" call, use ulaw for those if the bandwidth allows. that sort of thing.

Recording all calls also uses a lot of server process. Especially if you are running the crontab -e "mix/move" perl scripts all day long. Those audio file movements and mixing hit the cpu as does the writing of the audio files.

You could consider deactivating the mix/move crons until after the shift is over if you don't need to listen to them right away.

Or turn off recording during heavy load if you can.

[gardo]

And don't forget to use RAMdrives or tmpfs for your initial recordings storage. This avoids heavy disk IO bottlenecks (which tremendously increases the load average) when recording all calls.

[williamconley]

Doesn't goauto already use tmpfs? So that's already ... done?

[cbsys]

This is nothing to do with recordings!

It is very slow to load the admin pages, even when the dialler is completely idle and not doing anything!

[williamconley]

This is nothing to do with recordings!

It is very slow to load the admin pages, even when the dialler is completely idle and not doing anything!

Where'd you come from? Are you related to urmi.l?

If you don't like the goautodial admin pages, use the Vicidial admin pages. They don't require nearly as much "oomph" from your desktop web browser.

[gardo]

This is related to this: http://www.vicidial.org/VICIDIALforum/viewtopic.php?f=7&t=29496.

This is nothing to do with recordings!

It is very slow to load the admin pages, even when the dialler is completely idle and not doing anything!

[urmi.l]

Doesn't goauto already use tmpfs? So that's already ... done?

Do I need to set tmpfs or RAMdrive ? or go autodial already using it ?

[gardo]

You need to manually enable it. There are 2 ways:

Edit /etc/fstab and add the following line:

Code: Select all

tmpfs   /var/spool/asterisk/monitor   tmpfs   rw  0 0

Or edit /etc/rc.local and change the following from:

Code: Select all

### uncomment If kernel RAM drive is enabled
#mke2fs -m 0 /dev/ram0
#mount /dev/ram0 /var/spool/asterisk/monitor
#mkdir /var/spool/asterisk/monitor/DONE
#mkdir /var/spool/asterisk/monitor/ORIG

to this:

Code: Select all

### uncomment If kernel RAM drive is enabled
mke2fs -m 0 /dev/ram0
mount /dev/ram0 /var/spool/asterisk/monitor
mkdir /var/spool/asterisk/monitor/DONE
mkdir /var/spool/asterisk/monitor/ORIG

[urmi.l]

Thank you for your quick response. I have just edited /etc/fstab and add the following line:

tmpfs /var/spool/asterisk/monitor tmpfs rw 0 0

Do I need to follow any other instruction for setting up RAM drive as mentioned in below link ? Do I need to configure anything else ? if so then please guide me.
http://www.vicidial.org/VICIDIALforum/viewtopic.php?t=5129&highlight=

[urmi.l]

Below is my top results :

[root@localhost astguiclient]# top
top - 20:38:32 up 1 day, 6:13, 3 users, load average: 2.53, 2.14, 2.28
Tasks: 178 total, 1 running, 174 sleeping, 0 stopped, 3 zombie
Cpu0 : 39.5%us, 8.3%sy, 0.0%ni, 51.2%id, 0.0%wa, 0.0%hi, 1.0%si, 0.0%st
Cpu1 : 35.2%us, 9.3%sy, 0.0%ni, 51.2%id, 0.7%wa, 0.7%hi, 3.0%si, 0.0%st
Mem: 8179000k total, 1071352k used, 7107648k free, 6252k buffers
Swap: 10223608k total, 0k used, 10223608k free, 221144k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2889 mysql 15 0 976m 339m 4936 S 15.9 4.3 95:38.38 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql
13392 root 18 0 2344m 89m 6168 S 15.6 1.1 88:33.28 asterisk
25520 root 15 0 75008 9784 2820 S 4.0 0.1 4:42.01 /usr/bin/perl /usr/share/astguiclient/AST_update.pl
26372 root 19 0 32940 6124 1748 S 2.3 0.1 0:00.07 /usr/bin/perl /usr/share/astguiclient/AST_send_action_child.pl --SYSLOG
26398 root 24 0 32940 6120 1748 S 2.3 0.1 0:00.07 /usr/bin/perl /usr/share/astguiclient/AST_send_action_child.pl --SYSLOG
26368 root 18 0 32940 6124 1748 S 2.0 0.1 0:00.06 /usr/bin/perl /usr/share/astguiclient/AST_send_action_child.pl --SYSLOG
26376 root 19 0 32940 6128 1748 S 2.0 0.1 0:00.06 /usr/bin/perl /usr/share/astguiclient/AST_send_action_child.pl --SYSLOG
26383 root 21 0 32936 6124 1748 S 2.0 0.1 0:00.06 /usr/bin/perl /usr/share/astguiclient/AST_send_action_child.pl --SYSLOG
26385 root 22 0 32940 6124 1748 S 2.0 0.1 0:00.06 /usr/bin/perl /usr/share/astguiclient/AST_send_action_child.pl --SYSLOG
26387 root 23 0 32940 6124 1748 S 2.0 0.1 0:00.06 /usr/bin/perl /usr/share/astguiclient/AST_send_action_child.pl --SYSLOG
26370 root 17 0 32940 6128 1748 S 1.7 0.1 0:00.05 /usr/bin/perl /usr/share/astguiclient/AST_send_action_child.pl --SYSLOG
26381 root 21 0 32936 6128 1748 S 1.7 0.1 0:00.05 /usr/bin/perl /usr/share/astguiclient/AST_send_action_child.pl --SYSLOG
26392 root 23 0 32940 6128 1748 S 1.7 0.1 0:00.05 /usr/bin/perl /usr/share/astguiclient/AST_send_action_child.pl --SYSLOG
13500 root 15 0 76244 14m 2736 S 1.3 0.2 9:54.85 /usr/bin/perl /usr/share/astguiclient/AST_VDauto_dial.pl
9941 apache 15 0 322m 21m 12m S 1.0 0.3 0:20.97 /usr/sbin/httpd
9947 apache 15 0 322m 20m 11m S 1.0 0.3 0:20.98 /usr/sbin/httpd
9948 apache 15 0 322m 21m 12m S 1.0 0.3 0:20.98 /usr/sbin/httpd
13497 root 19 0 68164 6924 2740 S 1.0 0.1 3:41.41 /usr/bin/perl /usr/share/astguiclient/AST_manager_send.pl
14992 apache 15 0 321m 19m 11m S 1.0 0.2 0:14.63 /usr/sbin/httpd
19147 apache 15 0 321m 16m 8584 S 1.0 0.2 0:08.34 /usr/sbin/httpd
19314 apache 15 0 321m 14m 7124 S 1.0 0.2 0:07.99 /usr/sbin/httpd
22558 apache 15 0 321m 14m 7228 S 1.0 0.2 0:03.77 /usr/sbin/httpd
9755 apache 15 0 321m 20m 11m S 0.7 0.3 0:21.02 /usr/sbin/httpd
13927 apache 15 0 321m 21m 12m S 0.7 0.3 0:16.39 /usr/sbin/httpd
14876 root 15 0 12740 1180 804 S 0.7 0.0 0:05.59 top
15198 apache 15 0 321m 20m 11m S 0.7 0.3 0:14.37 /usr/sbin/httpd
22553 apache 15 0 321m 14m 6968 S 0.7 0.2 0:03.66 /usr/sbin/httpd
22557 apache 15 0 321m 19m 11m S 0.7 0.2 0:03.74 /usr/sbin/httpd
13502 root 15 0 74888 9544 2816 S 0.3 0.1 1:44.84 /usr/bin/perl /usr/share/astguiclient/AST_manager_listen.pl
14883 apache 15 0 321m 20m 12m S 0.3 0.3 0:14.78 /usr/sbin/httpd
18551 root 15 0 81252 10m 1540 S 0.3 0.1 0:00.74 /usr/bin/perl /usr/share/astguiclient/FastAGI_log.pl --debug
23630 root 15 0 86972 25m 2712 S 0.3 0.3 4:32.31 /usr/bin/perl /usr/share/astguiclient/AST_VDadapt.pl --debug
25127 root 15 0 90108 3360 2604 S 0.3 0.0 0:02.66 sshd: root@pts/10
25664 root 15 0 12740 1172 804 R 0.3 0.0 0:00.35 top
1 root 15 0 10348 688 576 S 0.0 0.0 0:06.31 init [5]

I dont understand why the load avg is too much high ? Due to this there is voice breackage issues. Need some suggesions pls.

[gardo]

Your load average is 2.53. The recommend load average for 2 cores is <2. Your load average translates to 253% utilization. A dual core server should have on the average less than 200% utilization (100% per core).

You might need to get a more powerful server or put Asterisk in a different server.

[williamconley]

Not that I would ever disagree with you Gardo, but we recommend 50% not 100%. We've found that planning for a cluster (or upgrade) at the 50% mark means that before 75% you can fix the problem. Anyone we've found regularly exceeding 50% usage (load average 1,5,10 minutes all cruising over 2.0 on a 4 processor system, for instance) will also be experiencing "issues" that can't be explained.

Perhaps I fall into the category of Brake Shop ("hey! that's pad is worn more than 5% replace it NOW!!"), but that's been our experience.

But for those of you who listen to me closely, in the case of a GoAuto install, go with Gardo's word. He's seen a lot more of those than I have.