我有一台裝有 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 內存，您是否會從 ECC 內存中受益。根據定義，您無法記錄檢測錯誤的失敗，而且您當然沒有關於可能發生或可能未發生的錯誤是否是記憶體控制器混亂的結果的資料。
也就是說，如果您運行 memtest，您將確定幾件事。如果您沒有發現錯誤，則您需要 ECC RAM，要么問題出在其他方面（因此，如果您完全排除所有硬體和軟體的原因，則表示您需要 ECC RAM）。如果您發現一致的錯誤，則 RAM 很可能已損壞，只需更換即可。如果您發現不一致的錯誤，則 CPU 可能已損壞，或者您可能需要 ECC RAM。如果你發現memtest86崩潰了，要嘛是最低階的DIMM壞了，要嘛是CPU壞了，要嘛是你需要ECC RAM。
無論如何，要明確地展示這一點是非常棘手的。 ECC RAM 在計算中的不可見錯誤可能導致極端問題的應用程式中最有用，或者在 RAM 數量與其他條件相結合導致統計上可能出現錯誤的應用程式中最有用。然而，這些標準本身是模糊和主觀的，因此實際上並沒有一個客觀的標準。
答案3
如果在任何地方，它可能會登入
/var/log/mcelog
（這是 RHEL 品種上發生關鍵 CPU 事件的地方）