Ich habe einen dedizierten Server mit 32 GB Nicht-ECC-RAM und CentOS.
Einmal am Tag stürzt es zufällig ab, ohne dass ein Fehler in /var/log/kern.log, /var/log/messages, mysql, apache auftritt.
CPU/RAM/IO sind weder besonders hoch noch besonders niedrig.
Gibt es irgendwo einen solchen von CentOS protokollierten Fehler, der schlüssig beweisen kann, dass es jetzt Zeit ist, für ECC zu bezahlen?
Antwort1
Was soll protokolliert werden? CentOS kann nicht wissen, dass der Inhalt des Nicht-ECC-Speichers beschädigt ist, weil es das nicht wissen kann. Es kann nur wissen, dass der Speicherinhalt keinen Sinn ergibt, und aufgrund der festgestellten Inkonsistenz in Panik geraten. Diese Inkonsistenz kann durch eine Beschädigung des RAM entstanden sein, aber auch durch einen Kernel-Fehler oder eine andere Ursache.
Die einzige Möglichkeit, definitiv festzustellen, ob der Speicher beschädigt ist, besteht darin, einen Speicher zu verwenden, der die Überprüfung auf derartige Beschädigungen ausdrücklich unterstützt (also einen ECC-Speicher).
Bearbeiten: das ist eine ganz andere Frage als die, die Sie gestellt haben. Aber meine Strategie wäre: Führen Sie es memtest86+auf der Hardware aus, um zu sehen, ob es leicht zu erkennende, wiederholbare Fehler gibt, und aktivieren Sie Remote- syslogGing auf dem Server (wenn der Kernel in Panik gerät, hört er oft auf, in das FS zu schreiben, kann aber immer noch eine Protokollnachricht aus der Netzwerkkarte herauspressen), um zu sehen, was bei der nächsten Panik protokolliert wird.
Antwort2
ECC-Speicher hat zwei Vorteile:
- Es ist registriert, was bedeutet, dass sich vor anderen Komponenten auf dem Chip ein Register befindet. Dies soll die elektrische Belastung des Speichercontrollers verringern. Dies gilt für alle RDIMMs, nicht nur für ECC-RAM.
- Es kann Fehler erkennen und, wenn nicht, sie beheben, zumindest melden, dass sie aufgetreten sind
Vor diesem Hintergrund ist es tatsächlich sehr schwierig zu bestimmen, ob Sie von ECC-RAM profitiert hätten, ohne ECC-RAM zu haben. Per Definition können Sie das Fehlschlagen der Fehlererkennung nicht protokollieren und Sie haben sicherlich keine Daten darüber, ob der Fehler, der möglicherweise aufgetreten ist oder nicht, das Ergebnis eines Fehlers des Speichercontrollers war.
Wenn Sie jedoch memtest ausführen, werden Sie einige Dinge feststellen. Wenn Sie keine Fehler finden, benötigen Sie entweder ECC-RAM oder das Problem liegt woanders (wenn Sie also absolut jede Hardware und Software als Ursache ausschließen, haben Sie gezeigt, dass ECC-RAM erforderlich ist). Wenn Sie konsistente Fehler finden, ist der RAM wahrscheinlich defekt und muss nur ersetzt werden. Wenn Sie inkonsistente Fehler finden, ist möglicherweise die CPU defekt oder Sie benötigen ECC-RAM. Wenn Sie feststellen, dass memtest86 abstürzt, ist entweder das DIMM mit der niedrigsten Ordnung defekt oder die CPU ist defekt oder Sie benötigen ECC-RAM.
Unabhängig davon ist es sehr schwierig, dies eindeutig nachzuweisen. ECC-RAM ist am nützlichsten bei Anwendungen, bei denen unsichtbare Berechnungsfehler wahrscheinlich extreme Probleme verursachen, oder bei Anwendungen, bei denen die schiere RAM-Menge in Kombination mit anderen Bedingungen Fehler statistisch wahrscheinlich macht. Diese Kriterien selbst sind jedoch schwammig und subjektiv, sodass es hierfür kein wirklich objektives Kriterium gibt.
Antwort3
Wenn irgendwo, dann würde es sich wahrscheinlich anmelden an
/var/log/mcelog
(hier gehen kritische CPU-Ereignisse auf RHEL-Breds hin)