I'm in the process of replacing an old server with a new one and are making som changes in the infrastructure, the biggest change in my eyes is moving from i386 to AMD64 arch. Yesterday I began migrating some users from the old to the new server. After only 57 concurrent calls in abount 13 conferences the sound are losing quality. The server uses dahdi 2.6.0 for timing but no dahdi hardware. dahdi_test gives results like this when the server is used like that: 100.000% 99.999% 99.994% 99.998% 99.999% 99.616% 99.614% 99.997% 99.998% 99.618% 99.615% 99.994% 99.987% 99.626% 99.628% 99.993% 99.626% 100.000% 100.000% 99.622% 99.999% 99.607% 99.604% 99.627% 99.621% 99.629% 99.627% 99.998% 99.622% 99.995% 99.621% 99.996% Results from dahdi_test with only some calls active: 99.999% 99.999% 99.990% 99.998% 99.999% 99.995% 99.995% 99.993% 99.997% 99.993% 99.999% 99.998% 99.996% 99.996% 99.998% 99.998% 99.991% 99.998% 99.995% 99.995% 99.987% 99.985% 99.996% 99.995% Looking at the cacti graphs the kernel uses 100% cpu (total 400% with 4 processor cores), when the problem above is present. Top does not show this kernel-cpu that cacti shows, but this maybe is by design? Asterisk is using about 15% cpu. top - 19:32:06 up 20:57, 1 user, load average: 0.00, 0.00, 0.00 Tasks: 213 total, 1 running, 212 sleeping, 0 stopped, 0 zombie Cpu(s): 7.4%us, 29.6%sy, 0.0%ni, 55.3%id, 0.0%wa, 0.0%hi, 7.7%si, 0.0%st Mem: 12299332k total, 3967800k used, 8331532k free, 251432k buffers Swap: 19529720k total, 0k used, 19529720k free, 2919456k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 30666 root 0 -20 539m 25m 6600 S 15 0.2 6:55.01 asterisk 738 root 20 0 19184 1444 1004 R 1 0.0 0:00.08 top The old server (i386 Debian 5: Linux 2.6.26-2-openvz-686) can have 320 calls in conferences without this problem. The new server (amd64 Debian 6: Linux 2.6.32-5-openvz-amd64) show these problems after 50 calls.. Old server: Hp dl360g5, 4 cpu Xeon E5420, 2.50GHz run i386 with PAE and OpenVZ, Debian Lenny uses the broadcom nic's on the motherboard asterisk 1.4.42 in openvz container (uses /dev/dahdi for timing) cacti shows cpu in kernel mode 80% with 320 active calls in conferences New server: Hp dl360g7, 4 cpu Xeon E5520, 2.27GHz run amd63 with OpenVZ, Debian Squeeze uses Intel nic's 82571EB for offloading the processor + nic bonding in the kernel for failover. asterisk 1.4.42 in openvz container (uses /dev/dahdi for timing) cacti show cpu in kernel mod 100% with 57 active calls in conferences This is a puzzle to me.. - Does anyone have experience with amd64 arch and dahdi for timing? - Can Dahdi om amd64 be responsible for the high cpu in kernel mode? - I have a spare Digium TE220, would it offload the server to use it as a timing source only? - How do I debug the high cpu usage by the kernel, can I break this down by module in some way? Many, many thanks! -- Johan Wilfer email: johan at jttech.se JT Tech | Developer webb: http://jttech.se
Hi Johan, I've run into a similar issue before. I didn't resolve the problem per se, but I got around it by modifying modules.conf to disable the loading of res_timing_timerfd.so and loaded res_timing_dahdi.so instead: noload => res_timing_timerfd.so load => res_timing_dahdi.so Cpu load came back down and call quality has been excellent since. Perhaps this might work for you? -- <http://www.classiccitytelco.com> *John Knight* Classic City Telco LLC *Email:* john at classiccitytelco.com | *Main:* (706) 995-0200 *Direct:* (706) 995-0201 | *Mobile:* (706) 255-9203 On 1/18/2012 4:24 AM, Johan Wilfer wrote:> I'm in the process of replacing an old server with a new one and are > making som changes in the infrastructure, the biggest change in my eyes > is moving from i386 to AMD64 arch. Yesterday I began migrating some > users from the old to the new server. > > After only 57 concurrent calls in abount 13 conferences the sound are > losing quality. > The server uses dahdi 2.6.0 for timing but no dahdi hardware. > > dahdi_test gives results like this when the server is used like that: > 100.000% 99.999% 99.994% 99.998% 99.999% 99.616% 99.614% 99.997% > 99.998% 99.618% 99.615% 99.994% 99.987% 99.626% 99.628% 99.993% > 99.626% 100.000% 100.000% 99.622% 99.999% 99.607% 99.604% 99.627% > 99.621% 99.629% 99.627% 99.998% 99.622% 99.995% 99.621% 99.996% > > Results from dahdi_test with only some calls active: > 99.999% 99.999% 99.990% 99.998% 99.999% 99.995% 99.995% 99.993% > 99.997% 99.993% 99.999% 99.998% 99.996% 99.996% 99.998% 99.998% > 99.991% 99.998% 99.995% 99.995% 99.987% 99.985% 99.996% 99.995% > > Looking at the cacti graphs the kernel uses 100% cpu (total 400% with 4 > processor cores), when the problem above is present. Top does not show > this kernel-cpu that cacti shows, but this maybe is by design? Asterisk > is using about 15% cpu. > > top - 19:32:06 up 20:57, 1 user, load average: 0.00, 0.00, 0.00 > Tasks: 213 total, 1 running, 212 sleeping, 0 stopped, 0 zombie > Cpu(s): 7.4%us, 29.6%sy, 0.0%ni, 55.3%id, 0.0%wa, 0.0%hi, 7.7%si, > 0.0%st > Mem: 12299332k total, 3967800k used, 8331532k free, 251432k buffers > Swap: 19529720k total, 0k used, 19529720k free, 2919456k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 30666 root 0 -20 539m 25m 6600 S 15 0.2 6:55.01 asterisk > 738 root 20 0 19184 1444 1004 R 1 0.0 0:00.08 top > > > The old server (i386 Debian 5: Linux 2.6.26-2-openvz-686) can have 320 > calls in conferences without this problem. > The new server (amd64 Debian 6: Linux 2.6.32-5-openvz-amd64) show these > problems after 50 calls.. > > Old server: > Hp dl360g5, 4 cpu Xeon E5420, 2.50GHz > run i386 with PAE and OpenVZ, Debian Lenny > uses the broadcom nic's on the motherboard > asterisk 1.4.42 in openvz container (uses /dev/dahdi for timing) > cacti shows cpu in kernel mode 80% with 320 active calls in conferences > > New server: > Hp dl360g7, 4 cpu Xeon E5520, 2.27GHz > run amd63 with OpenVZ, Debian Squeeze > uses Intel nic's 82571EB for offloading the processor + nic bonding in > the kernel for failover. > asterisk 1.4.42 in openvz container (uses /dev/dahdi for timing) > cacti show cpu in kernel mod 100% with 57 active calls in conferences > > This is a puzzle to me.. > - Does anyone have experience with amd64 arch and dahdi for timing? > - Can Dahdi om amd64 be responsible for the high cpu in kernel mode? > > - I have a spare Digium TE220, would it offload the server to use it as > a timing source only? > - How do I debug the high cpu usage by the kernel, can I break this > down by module in some way? > > > Many, many thanks! >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20120118/184c9539/attachment.htm> -------------- next part -------------- A non-text attachment was scrubbed... Name: logo2.jpg Type: image/jpeg Size: 9505 bytes Desc: not available URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20120118/184c9539/attachment.jpg>
In article <4F168FCC.9070300 at jttech.se>, Johan Wilfer <lists at jttech.se> wrote:> I'm in the process of replacing an old server with a new one and are > making som changes in the infrastructure, the biggest change in my eyes > is moving from i386 to AMD64 arch. Yesterday I began migrating some > users from the old to the new server. > > [...] > > The old server (i386 Debian 5: Linux 2.6.26-2-openvz-686) can have 320 > calls in conferences without this problem. > The new server (amd64 Debian 6: Linux 2.6.32-5-openvz-amd64) show these > problems after 50 calls.. > > Old server: > Hp dl360g5, 4 cpu Xeon E5420, 2.50GHz > run i386 with PAE and OpenVZ, Debian Lenny > uses the broadcom nic's on the motherboard > asterisk 1.4.42 in openvz container (uses /dev/dahdi for timing) > cacti shows cpu in kernel mode 80% with 320 active calls in conferences > > New server: > Hp dl360g7, 4 cpu Xeon E5520, 2.27GHz > run amd63 with OpenVZ, Debian Squeeze > uses Intel nic's 82571EB for offloading the processor + nic bonding in > the kernel for failover. > asterisk 1.4.42 in openvz container (uses /dev/dahdi for timing) > cacti show cpu in kernel mod 100% with 57 active calls in conferences > > This is a puzzle to me.. > - Does anyone have experience with amd64 arch and dahdi for timing? > - Can Dahdi om amd64 be responsible for the high cpu in kernel mode?It may be a stupid question just displaying ignorance on my part, but why are you using *AMD*64 architecture on an *Intel* processor? Surely for 64-bit, you should be using x86_64 architecture instead? Cheers Tony -- Tony Mountifield Work: tony at softins.co.uk - http://www.softins.co.uk Play: tony at mountifield.org - http://tony.mountifield.org