我有一台装有 CentOS 的 32GB 非 ECC RAM 专用服务器。
每天它会随机崩溃一次，而 /var/log/kern.log、/var/log/messages、mysql、apache 中没有任何错误。
CPU/RAM/IO 没有特别高也没有特别低。
CentOS 是否在某处记录了此类错误，可以明确揭示“现在是时候支付 ECC 了”？
答案1
您希望它记录什么？ CentOS 无法知道非 ECC 内存的内容已损坏，因为这是不可知的；它只能知道内存的内容没有意义，并根据它发现的任何自不一致而恐慌。这种不一致可能是由 RAM 损坏引起的，但也可能是由内核错误或其他原因引起的。
确切知道内存是否已损坏的唯一方法是使用明确支持检查此类损坏的内存；即 ECC 内存。
编辑：这与你问的问题完全不同。但我的策略是：memtest86+在硬件上运行，看看是否有任何容易捕获的可重复错误，并syslog在服务器上启用远程 ging（因为当内核崩溃时，它通常会停止写入 FS，但仍可以从 NIC 中挤出日志消息），看看下次崩溃时会记录什么。
答案2
ECC内存有两个优点：
- 它已注册，这意味着在芯片上的其他组件之前有一个寄存器。这是为了消除内存控制器的电气负载。这适用于所有 RDIMM，而不仅仅是 ECC RAM。
- 它可以检测错误，如果不能恢复，至少可以报告错误发生
鉴于此，实际上很难确定如果没有 ECC RAM，ECC RAM 是否会对您有益。根据定义，您无法记录检测错误的失败，并且您肯定没有数据来判断可能发生或可能未发生的错误是否是内存控制器混乱的结果。
也就是说，如果您运行 memtest，您将确定几件事。如果您没有发现错误，则要么您需要 ECC RAM，要么问题出在其他方面（因此，如果您完全排除所有硬件和软件作为原因，则表明需要 ECC RAM）。如果您发现一致的错误，则很可能是 RAM 坏了，只需更换即可。如果您发现不一致的错误，则可能是 CPU 坏了，或者您可能需要 ECC RAM。如果您发现 memtest86 崩溃，则要么是最低阶 DIMM 坏了，要么是 CPU 坏了，要么您需要 ECC RAM。
无论如何，要明确地展示这一点非常困难。ECC RAM 最适用于计算中不可见的错误可能导致极端问题的场合，或者 RAM 数量与其他条件相结合导致统计上可能出现错误的场合。然而，这些标准本身是模糊和主观的，因此实际上没有一个客观的标准。
答案3
如果有的话，它可能会记录到
/var/log/mcelog
（这是 RHEL 版本中发生关键 CPU 事件的地方）