CentOS を搭載した 32GB 非 ECC RAM 専用サーバーを所有しています。
1 日に 1 回、/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 メモリには 2 つの利点があります。
- レジスタ付き、つまりチップ上の他のコンポーネントの前にレジスタがあります。これにより、メモリ コントローラから電気的な負荷が取り除かれるはずです。これは、ECC RAM だけでなく、すべての RDIMM に当てはまります。
- エラーを検出し、回復できない場合でも少なくともエラーが発生したことを報告します。
これを考慮すると、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 イベントがここに発生します)