Lots Of Calls, Less Memory

Home » Asterisk Users » Lots Of Calls, Less Memory
Asterisk Users 6 Comments

We’re running Asterisk 1.8 on a 32-bit Debian machine, and it has been fine for some time now. But! We’ve got such a incoming call volume over the few weeks that we’ll have Asterisk occasionally restart itself. My hunch is that it is in part memory pressure.

I can’t add RAM and have it help, because it’s 32-bit. I intend to move to a 64-bit machine, but I was hoping to wait until summer. Does anyone have any immediate tips for dealing with this sort of rush?

Justin Sherrill – American Rock Salt P: 585-991-6825 F: 585-991-6925

6 thoughts on - Lots Of Calls, Less Memory

  • Rather than speculate, take a look at the output of “top”. If you’re running out of memory, shut down useless processes. You’d be surprised what processes get started by default that you don’t need. You should also check the Asterisk logs and look at the last few things Asterisk did right before it restarted. You may also want to consider not loading Asterisk modules that you are never going to use. Just a suggestion. Regards;
    John

    —–Original Message—

  • I’m a 1.2 Luddite, but…

    I suspect it’s not RAM.

    I have a CentOS 32bit box with 2GB that has 350 calls right now (last night’s peak was 420), most in meetme conferences.

    How many concurrent calls are you handling?

    How much RAM is Asterisk consuming on your box?

    Any obese AGIs? I run tons of AGIs, but I write them in C.

    Does ‘vmstat 5’ show swapping?

  • To follow up the discussion – yeah, it’s not RAM, or at least not directly. I’m so used to looking in the asterisk logs I didn’t think to look at /var/log/messages:

    Feb 10 09:10:45 telephone-retsof kernel: [35734.705648] asterisk[11215]: segfault at ffa2048e ip b70a3def sp b540a000 error 4 in libpri.so.1.4[b708b000+47000]

    We are slightly behind the current libpri release.

  • how about running “free” or “vmstat” inside cron every hour or so?
    If you do a “vmstat 1 10” each hour on the hour, it tells you 10 times with one second interval the amount of mem you got. If you do that within cron, you can see the difference during a couple of days.

    Running out of mem, will cause unexpected results (to be found in syslog), though rebooting should not be one of them.

    for unintended reboots there are a lot of hardware related causes though Some are easier to detect (like high temp) some are harder. My most favorite is a moron-co-worker, touching sensative parts (cpu, mem, mobo) with his ESD-unprotected hands. Problems might show up even after months or years after the crime has been commited.

    hw