☰

FreePBX 服务器（基于 cent OS）锁定，没有错误或内核崩溃

tag-icon • tag-icon linux centos freepbx
FreePBX 服务器（基于 cent OS）锁定，没有错误或内核崩溃

几天来我一直在处理这种令人困惑的情况。我有多个 CentOS 无头服务器 (6.4)，其统计数据如下：

核

  • CentOS - 6.4（最终版本）
  • 内核 - 2.6.32-358.14.1.el6.x86_64
  • 免费PBX - 4.211.64-9
  • 主板 - 华硕 P8H61
  • CPU - 英特尔酷睿 i3 3.4GHZ
  • 内存 - 8GB 金士顿 DDR3 800-1600
  • 硬盘 - WD Black 7200 RPM
  • PRI - Digium 设备 TE130 800a (rev 02)
  • PRI - Sangoma B600 (1923:0025)

  • SE 状态：已禁用（我知道，我知道）

    套餐

  • libpri-1.4.12-6_centos6.x86_64

  • libpri-调试-信息-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-内核.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

当此设置工作时，效果非常好。十台位于不同位置的服务器在硬件和软件方面都运行相同的设置。然而，十台服务器中有三台一直处于锁定状态。所谓锁定，是指网络完全无响应，无法发送或接收任何电话。需要强制关闭/重启服务器才能使其再次运行。

/var/log/messages、dmesg 和 dmesg,old 在系统锁定时停止记录，但日志中不包含任何错误、硬件错误、恐慌等信息。/var/log/boot 显示正常启动，只有几个关于 prodigy（未使用）的警告。/var/log/mcelog 始终为空，没有行数或文本。/var/log/freepbx.log 显示正常的信息行。

与锁定相关的服务器的时间范围或工作量没有规律。有时会持续三个小时，有时会持续三天。传感器显示温度始​​终在范围内，并且没有记录 CPU 阈值日志。我已经安装了 kdump 并将内核参数设置为在软锁定和挂起任务时崩溃，以及默认值。kdump.conf 已更改为默认重启。当我手动 SYSRQ C（内核崩溃）时，会触发 kdump 并转储崩溃文件（尽管出于某种原因它不会在那之后自动重启）。CPU 的 SAR 使用率从未超过 5% 的利用率，内存的利用率从未超过 10%。HDD rd_sec 的峰值为 5.86，wr_sec 的峰值为 120。最大利用率平均约为 7%。

我运行了 memtester 并对系统施加压力，试图让其崩溃，但无济于事（系统需要尽可能保持运行）。Memtester 以 512M 和 50 次迭代运行，最高以 2048M 和 100 次迭代运行，所有测试都“正常”没有问题。

我看不出这些框锁定的任何原因，或者为什么 kdump 没有被触发（如果是内核崩溃）。我已经用尽了我的日志搜索技能来尝试找到这种行为的原因。

还有谁知道我应该去哪里查找，或者我应该做什么来查明这里的问题？

相关内容