[asterisk-users] VERY HIGH LOAD AVERAGE: top - 10:27:57 up 199 days, 5:18, 2 users, load average: 67.75, 62.55, 55.75

Muro, Sam research at businesstz.com
Wed Feb 10 01:25:07 CST 2010


>> Hi Team
>>
>> Can someone advice me on how i can lower the load average on my
asterisk server?
>>
>> dahdi-linux-2.1.0.4
>> dahdi-tools-2.1.0.2
>> libpri-1.4.10.1
>> asterisk-1.4.25.1
>>
>> 2 X TE412P Digium cards on ISDN PRI
>>
>> Im using the system as an IVR without any transcoding or bridging
>>
>> **************************************
>> top - 10:27:57 up 199 days,  5:18,  2 users,  load average: 67.75, 62.55,
>> 55.75
>>
>
> Hi Sam!

Hello Steve!
>
> Are there any side-effects from the high load average?  The system
doesn't seem to be CPU or disk bound from the look of the CPU stats. 
System %age is
> high by way - software echo cancellaton?, and Asterisk is using a lot of
cpu
> which isn't suprising.
>
Yes. Audio quality issues. I have enabled the hardware echo cancellation
and configured
echocancel=yes
echocancelwhenbridged=yes
echotraining=yes


> I'm guessing you are running 8 spans and 200+ calls into your IVR?
>

You are correct. 8 span which process up to 240 calls at pick time

> If the system is actually performing fine then I'd just say that there
is something about the Asterisk threads that makes them look runnable
and that
> accounts for the high load average.  Is the IVR an agi or fastagi or
what? -

I have the agi scripts not as ivr but to help populate the required
information into mysql db. Probably here is where the problem lies i have
to connect and disconnect to mysql each time a call is made or a specific
menu is selected

Here is the script
*****
#!/usr/bin/perl -w
use strict;
use DBI();
use Scalar::Util qw/weaken/;

my $cdr_log_file = "/var/log/asterisk/ivr_log";
my $mysql_host = "cdr01";
my $mysql_db = "ivrcdrdb";
my $mysql_table = "tbl_ivrcdr_details";
my $mysql_user = "ivruser";
my $mysql_pwd = "a09876a";


my $sth;

my $data0= $ARGV[0];
my $data1= $ARGV[1];
my $data2= $ARGV[2];
my $data3= $ARGV[3];
my $data4= $ARGV[4];
my $data5= $ARGV[5];
my $data6= $ARGV[6];
my $data7= $ARGV[7];


# Connect to database
# print "Connecting to database...\n\n";
my $dbh =
DBI->connect("DBI:mysql:database=$mysql_db;host=$mysql_host","$mysql_user","$mysql_pwd",{'RaiseError'
=> 1});

my $insert_str = "insert into $mysql_table (calldate, language, src,
duration, accountcode, uniqueid, currentmenu, nextmenu) values
(\"$data0\", \"$data1\", \"$data2\", \"$data3\",  \"$data4\", \"$data5\",
\"$data6\", \"$data7\");\n";
       $sth = $dbh->prepare($insert_str);
       $sth->execute();

# print "\n\nOK.\n";

$sth->finish();
$dbh->disconnect();


# Trying to resolve memory leak should it happen
delete($ARGV[0]);
delete($ARGV[1]);
delete($ARGV[2]);
delete($ARGV[3]);
delete($ARGV[4]);
delete($ARGV[5]);
delete($ARGV[6]);
delete($ARGV[7]);


exit;
*********************

> the code path may have a "spinlock" logic to it that means that many
threads
> are runnable but when scheduled just go back to sleep.  That would
account for high load average with lots of spare CPU.  If that's what is
happening then I wouldn't worry much more about it.
>
> Regards,
> Steve

Regards
Sam





More information about the asterisk-users mailing list