Lösung 1:
mcelog überwacht den Speichercontroller und meldet Speicherfehlerereignisse an Syslog und kann in einigen Konfigurationen fehlerhafte Speicherseiten offline schalten. Dies geschieht natürlich zusätzlich zu seiner üblichen Verwendung zur Überwachung von Maschinenüberprüfungsausnahmen und einer Vielzahl anderer Hardwarefehler.
Die meisten Linux-Distributionen haben einen Dienst eingerichtet, um sie als Daemon auszuführen, z. für EL6:
chkconfig mcelog on
service mcelog start
Lösung 2:
Der Linux-Kernel unterstützt die Funktionen zur Fehlererkennung und -korrektur (EDAC) einiger Chipsätze. Auf einem unterstützten System mit ECC ist der Status Ihres Speichercontrollers über sysfs:
zugänglich/sys/devices/system/edac/mc
Der Verzeichnisbaum unter diesen Orten sollte Ihrer Hardware entsprechen, z. B.:
/sys/devices/system/edac/mc/mc0/csrow2/power
/sys/devices/system/edac/mc/mc0/csrow0/power
/sys/devices/system/edac/mc/mc0/dimm2/power
/sys/devices/system/edac/mc/mc0/dimm0/power
/sys/devices/system/edac/mc/mc1/power
...
Abhängig von Ihrer Hardware müssen Sie ggf. explizit den richtigen edac-Treiber laden, vgl.:
find /lib/modules/$(uname -r) -name '*edac*'
Die edac-utils Paket bietet ein Befehlszeilen-Frontend und eine Bibliothek für den Zugriff auf diese Daten, z. B.:
edac-util -rfull
mc0:csrow0:mc#0memory#0:CE:0
mc0:csrow2:mc#0memory#2:CE:0
mc0:noinfo:all:UE:0
mc0:noinfo:all:CE:0
mc1:noinfo:all:UE:0
mc1:noinfo:all:CE:0
Sie können eine Art Cron-Job einrichten, der regelmäßig eac-util aufruft und speist die Ergebnisse in Ihr Überwachungssystem ein, wo Sie dann einige Benachrichtigungen konfigurieren können.
Führen Sie außerdem mcelog aus ist generell eine gute Idee. Hängt vom System ab, aber nicht korrigierbare/korrigierbare ECC-Fehler werden wahrscheinlich auch als Machine Check Exception (MCE) gemeldet. Ich meine, selbst kurze Perioden von CPU-Throttling aufgrund höherer Temperatur werden als MCE gemeldet.
Lösung 3:
Dies hängt von Ihrer Serverhardware ab. Eine Whitebox oder ein Supermicro-System handhabt dies anders als ein Dell, HP oder IBM...
Eines der Mehrwertmerkmale von High-End-Servern ist, dass es ein gewisses Maß an Hardware-/Betriebssystem-Integration gibt. Nicer-Server melden, wonach Sie suchen, als Teil der Management-Agenten und/oder Out-of-Band-Management-Lösung (ILO, DRAC, IPMI).
Sie sollten die nativen Tools Ihrer Hardwareplattform verwenden.
Auszug aus einem HP ProLiant Server mit Linux und den HP Management Agents:
Trap-ID=6056
ECC Memory Correctable Errors detected.
und
Trap-ID=6052
Advanced ECC Memory Engaged
oder schwerer
Trap-ID=6029
A correctable memory log entry indicates a memory module needs to be
replaced.
oder das Schlimmste... Einen Fehler 6 Tage lang ignorieren, bis der Server wegen schlechtem RAM abstürzt
0004 Repaired 22:21 12/01/2008 22:21 12/01/2008 0001
LOG: Corrected Memory Error threshold exceeded (Slot 1, Memory Module 1)
0007 Repaired 02:58 12/07/2008 02:58 12/07/2008 0001
LOG: POST Error: 201-Memory Error Single-bit error occured during
memory initialization,
Board 1, DIMM 1. Bank containing DIMM(s) has been disabled.
0008 Repaired 19:31 12/08/2009 19:31 12/08/2009 0001
LOG: ASR Detected by System ROM
Diese wurden protokolliert, außerdem wurden SNMP-Traps und E-Mails gesendet.
Im Allgemeinen sehen Sie Machine Check Exceptions im Ringpuffer des Kernels, sodass Sie dmesg überprüfen können oder mcelog ausführen. In meinen Erfahrungen mit Supermicro-Ausrüstung ohne IPMI hat das nicht alles erfasst, und ich hatte immer noch RAM-Fehler, die durch die Ritzen schlüpften und Ausfälle verursachten. Leider führte dies zu archaischen RAM-Burn-In-Richtlinien vor der Systembereitstellung.
Lösung 4:
Die rasdaemon Paket wurde als Ersatz für edac-tools erstellt , und neuere Kernel unterstützen nicht einmal edac-tools oder mcelog .
Eine Aktualisierung der EDAC-Linux-Kernel-Treiber hat geändert, wie die Speicherfehlerzähler im Userspace verwaltet wurden, also edac-tools und mcelog sind effektiv veraltet.