高负载,低 CPU、内存和磁盘 IO - 高端服务器

高负载,低 CPU、内存和磁盘 IO - 高端服务器

这个问题困扰了我好几天,我花了 40 多个小时深入研究这个问题。

实际上,我们运行的是 Aterisk 1.4.42,据我所知,它已经很旧了,但它是最后一个真正稳定的 Aterisk 版本,在传真方面可以与我们的上游提供商配合使用(无法升级)。

现在的问题是,我们有以下规格的服务器:

戴尔 Poweredge 1950

四核 Xeon 2.5Ghz E5420

8 GB ECC 内存

4 个 73GB SAS 10k RPM 硬盘

戴尔 PERC 5 RAID 控制器处于 Raid 10 状态

Centos 5.9 X64

磁盘格式化 EXT3

现在的问题是,我们在 asterisk 中 100 个并发呼叫时服务器负载非常高。我搞不清楚。我有另一台具有类似规格的服务器,但它有 Quad core2duo、raid 1、2 x 250GB 7,200 RPM HD 和 8GB 非 ECC ram,可处理 200 多个并发呼叫,服务器负载约为 0.3。

我真的对此束手无策,无法弄清楚。

我附上了 top 和 iotop 结果的屏幕截图

屏幕截图显示 CPU 使用率低、内存使用率低且磁盘 IO 等待时间为 0%

顶部 -http://chostwales.com/images/hosted/Super-load.jpg

iotop-http://chostwales.com/images/hosted/HighDISKIO.jpg

如能得到任何帮助/想法我将非常感激。

需要澄清的是,这是 100 个并发呼叫,每秒大约有 1 个新呼叫。(如上所述,我的服务器规格低得多,每秒进行 10 个新呼叫,负载几乎没有变化)

澄清:

  • 禁止通话录音/监听
  • 转码约占通话的 30%。(不过从理解上看,这是 CPU 占用)
  • 我们没有运行任何 PRI

cat /proc/interrupts 显示(当前没有系统利用率)

[root@IS-21418 ~]# cat /proc/interrupts
           CPU0       CPU1       CPU2       CPU3       
  0:    7855099          0          0          0    IO-APIC-edge  timer
  1:          3          0          0          0    IO-APIC-edge  i8042
  8:          1          0          0          0    IO-APIC-edge  rtc
  9:          0          0          0          0   IO-APIC-level  acpi
 12:          4          0          0          0    IO-APIC-edge  i8042
 66:         24          0          0          0   IO-APIC-level  ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb4
 74:         34     106102          0          0   IO-APIC-level  uhci_hcd:usb3, uhci_hcd:usb5
 82:       4143      50727          0          0   IO-APIC-level  megasas
 90:     123985          0          0          0         PCI-MSI  eth0
NMI:        435        195        209        215 
LOC:    7852754    7851976    7852615    7851820 
ERR:          0
MIS:          0


[root@IS-21418 ~]# vmstat 1 20
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 7318888  23108 296540    0    0   125    61 1169 2581  2  3 93  1  0
 0  0      0 7318708  23124 296524    0    0     8   280 9704 20440  7  6 87  0  0
 0  0      0 7318820  23140 296768    0    0   128   280 9144 19752  2  5 93  0  0
 0  0      0 7318820  23180 296728    0    0     0  1620 8162 16012  2  2 97  0  0
 0  0      0 7318940  23208 296760    0    0    12   392 9729 22355  3  5 92  0  0
 0  0      0 7318544  23216 296752    0    0     0   100 9679 20152  2  2 96  0  0
 0  0      0 7317852  23232 296836    0    0     8   332 9753 21294  8  9 84  0  0
 0  0      0 7317720  23240 296828    0    0     4   160 9702 22166  3  3 95  0  0
 0  0      0 7317612  23248 296908    0    0     0   192 9643 20168  1  4 95  0  0
 0  0      0 7317340  23256 296900    0    0     0   112 9043 19541  2  2 96  0  0
 0  0      0 7315860  23264 296944    0    0     4   156 9025 21814  3  4 92  0  0
 0  0      0 7315624  23288 297176    0    0   140   504 9221 19047  6  6 87  1  0
 0  0      0 7314872  23296 297140    0    0     4   112 9499 21123  3  8 89  0  0
 3  0      0 7314492  23344 297092    0    0     4  1784 9725 24151  5  6 88  0  0
 1  0      0 7314796  23352 297192    0    0     0   176 9624 22662  4  7 89  0  0
 3  0      0 7314556  23368 297176    0    0     4   220 9789 23502  5  6 88  0  0
 2  0      0 7313820  23384 297196    0    0     4   348 9531 23117 14 13 74  0  0
 1  0      0 7313468  23432 297148    0    0    12   504 9852 25504  6 11 83  0  0
 2  0      0 7313104  23440 297268    0    0     4   112 9610 26564  6  7 88  0  0
 0  0      0 7312364  23464 297244    0    0   128   356 9608 23673  5  8 87  0  0

Dmesg 链接如下

亲切的问候

答案1

这类事情变化很大。例如,您是否在录制通话?如果是,您使用的是 Monitor 还是 MixMonitor?Monitor 与通话在同一个线程中处理,MixMonitor 在自己的线程中处理。如果您正在录制,则可能会遇到严重的磁盘问题。我通过关闭 /etc/fstab 中的 atime 解决了部分问题。

您可以通过运行 vmstat 来了解系统中正在发生的事情。简单的 vmstate 1 20 将为您提供 optput 来查看,您可以看到哪些东西占用了 CPU。

您还可以使用 asterisk 执行的另一项操作,即通过在 modules.conf 中添加“noload =>”行来删除不需要的模块。通常有很多模块。您只需花一些时间了解您使用和不使用的模块,因为所有模块都会在启动时自动加载。

还有一件事需要考虑,那就是转码。如果您使用 G.729A 编解码器接听电话,而您的软件电话/台式电话使用 G.711u,那么您的性能就会受到影响,因为它必须对这些编解码器进行转码,而不能只执行数据包到数据包的桥接。

答案2

我发现 Munin 有助于识别瓶颈。当某个图表的扩展性不如其他图表时,您可以轻松发现限制。

相关内容