FreePBX服务器(cent OS基础)locking,没有错误或内核恐慌

我已经处理了几天的一个令人困惑的情况。 我有多个CentOS无头服务器(6.4),具有以下属性:

核心

  • CentOS – 6.4(最终)
  • 内核 – 2.6.32-358.14.1.el6.x86_64
  • FreePBX – 4.211.64-9
  • MoBo – 华硕P8H61
  • CPU – 英特尔酷睿i3 3.4GHZ
  • Mem – 8GB金士顿DDR3 800-1600
  • 硬盘 – WD黑色7200转
  • PRI – Digium Device TE130 800a(rev 02)
  • PRI – Sangoma B600(1923:0025)
  • SE状态:禁用(我知道,我知道)

  • libpri-1.4.12-6_centos6.x86_64

  • libpri-debugging信息,1.4.12-6_centos6.x86_64
  • libpridevel – 1.4.12-6_centos6.x86_64

  • DAHDI-固件oct6114-128-1.05.01-119_centos5.noarch

  • DAHDI-Linux的2.7.0-18_centos6.x86_64

  • wanpipe-7.0.4-kernel.2.6.32.358.14.1.el6.dahdi.2.7.0.rel.49.x86_64
  • DAHDI-linux的-的kmod-debuginfo软,2.7.0-45_centos6.2.6.32_358.14.1.el6.x86_64.x86_64
  • DAHDI-linux的-debuginfo软,2.7.0-18_centos6.x86_64
  • DAHDI-固件oct6114-032-1.07.01-119_centos5.noarch
  • KMOD-DAHDI-Linux的2.7.0-45_centos6.2.6.32_358.14.1.el6.x86_64.x86_64
  • DAHDI-固件oct6114-256-1.05.01-119_centos5.noarch
  • DAHDI-固件te820-1.76-119_centos5.noarch
  • DAHDI-固件vpmoct032-1.12.0-119_centos5.noarch
  • DAHDI-固件2.5.0.1-119_centos5.noarch
  • DAHDI-linux的-devel的-2.7.0-18_centos6.x86_64
  • DAHDI-固件xorcom-1.0-1.noarch
  • DAHDI工具-debuginfo软,2.7.0-37_centos6.x86_64
  • DAHDI-固件oct6126-128-01.07.04-119_centos5.noarch
  • DAHDI-固件oct6114-064-1.05.01-119_centos5.noarch
  • DAHDI-固件hx8-2.06-119_centos5.noarch
  • DAHDI-固件tc400m-MR6.12-119_centos5.noarch
  • schmooze-dahdi-1.0.0-2.noarch dahdi-tools-2.7.0-37_centos6.x86_64
  • DAHDI工具-DOC-2.7.0-37_centos6.x86_64

当这个设置工作,它工作很好。 在不同地点的十台服务器运行相同的设置硬件和软件明智。 然而,十台服务器中有三台仍然保持locking状态。 通过locking,我的意思是在networking上完全没有响应,并且不能发送或接收电话。 它需要服务器的硬关机/重启才能使其重新运行。

/ var / log / messages,dmesg和dmesg,当系统锁死时,旧的只停止录制,但没有错误,硬件错误,恐慌等在日志中。 / var / log / boot显示一个正常启动,只有一些关于神童(这是不使用)的警告。 / var / log / mcelog总是空的,没有行数或文本。 /var/log/freepbx.log显示正常的INFO行。

与locking相关的服务器的时间框架或工作负载没有任何模式。 有时会三个小时,有时三天。 传感器显示温度始​​终在范围内,并且不loggingCPU阈值日志。 我已经安装kdump,并设置内核参数在softlockup和挂任务,以及默认值恐慌。 kdump.conf已更改为默认重新启动。 当我手动SYSRQ C(内核恐慌)时,kdump被触发并转储一个崩溃文件(尽pipe由于某种原因它不会自动重启)。 CPU的SAR使用率永远不会超过5%的利用率,内存永远不会超过10%的利用率。 HDD rd_sec峰值为5.86,wr_sec峰值为120.最大实用程序的平均值约为7%。

我已经运行memtester和压力的系统,尝试使其崩溃,无济于事(系统需要保持尽可能)。 Memtester以512M和50次迭代运行,最高可达2048M和100次迭代,都testing过“没问题”。

我看不到任何这些盒子locking的原因,或者为什么kdump没有被触发(如果它是一个内核恐慌)。 我已经耗尽了我的日志search技能,试图find这种行为的原因。

有没有其他人有一个想法,我可以看看,或者我可以做什么来查明问题在这里,请?