Speicherfehler unter Linux erkennen und beobachten

Maxim Kazmin, 123RF

Kippende Bits

Weil Hauptspeicher wichtig ist, benutzen viele Systeme Fehlerkorrekturmechanismen (ECC). Sie erkennen und berichtigen Einzelbitfehler. Linux kann Informationen darüber sammeln und ausgeben.
Termine planen, Nachrichten austauschen, Kundendaten verwalten, am besten auch vom Smartphone aus. Das alles und noch viel mehr sollen moderne ... (mehr)

ECC (Error Correcting Code) ist eine Schlüsseltechnologie, um in einem Rechnersystem Daten zu schützen und Fehler zu erkennen. Dabei kann Standard-ECC-Memory, wie es heute in vielen Systemen verbaut wird, Einzelbitfehler erkennen und beheben. Doppelbitfehler werden zwar ebenfalls erkannt, können aber nicht ausgeglichen werden.

Das Umkippen eines einzelnen Bits in einem Byte kann dramatische Folgen haben. Wenn beispielsweise in einem Byte mit dem Wert 156 (10011100) das zweite Bit kippen würde (11011100), ergäbe sich ein Wert von 220. ECC kann diesen Fall entdecken und berichtigen, sodass der Anwender nichts davon merkt. Würden allerdings zwei Bits ihren Wert ändern, würde das zwar bemerkt, das Ergebnis wäre dann aber eine Machine Check Exception, die in einen Systemabsturz mündet.

Solche umkippenden Bits werden von elektrischen oder magnetischen Störungen verursacht. Einem Wikipedia-Artikel [1] und einer Studie über Einzelbitfehler im RAM [2] zufolge, gehen die meisten kippenden Bits auf das Konto der kosmischen Hintergrundstrahlung (hauptsächlich Neutronen). Die zwischen 2007 und 2009 ermittelten Fehlerraten schwanken zwischen 1010 und 1017 Fehler pro Bitstunde (Unterschied: sieben Größenordnungen!). Der niedrigere Wert entspricht einem Fehler pro Gigabit pro Stunde. Der höhere Wert ungefähr einem Fehler pro Gigabit in 1000 Jahren.

Eine Studie von Google (siehe Kasten "Korrigierbare Fehler") deutet darauf hin, dass Fehler im realen Leben viel häufiger sind. Diese Fehlerraten zu beobachten ist wichtig, denn sie sind ein genereller Indikator für Speicherfehler.

Korrigierbare Fehler

Google hat einmal reale Speicherfehler untersucht [3]. Sie fanden heraus, dass ein Drittel der beteiligten Rechner und mehr als acht Prozent der DIMMs während eines Jahres korrigierbare Speicherfehler aufwiesen. Das entsprach einer Beobachtung von Google, derzufolge es zu 25 000 bis 75 000 korrigierbaren Fehlern pro einer Milliarde Gerätestunden pro Megabit kommt (oder 250 bis 750 Fehlern pro Gigabit pro Jahr). Das ist viel mehr als die zuvor als hoch angenommene Fehlerrate von einem Fehler pro Gigabit pro Jahr.

Die Studie erbrachte noch weitere interessante Ergebnisse:

  • Hat ein DIMM korrigierbare Fehler, ist es 13 bis 228 mal wahrscheinlicher, dass im selben Monat weitere Fehler auftreten.
  • In 70 bis 80 Prozent der Fälle gehen einem nicht korrigierbaren Fehler korrigierbare Fehler voraus. Korrigierbare Fehler erhöhen die Wahrscheinlichkeit für nicht korrigierbare Fehler um einen Faktor 9 bis 400.
  • Das Auftreten korrigierbarer Fehler nimmt mit dem Alter zu, aber nicht korrigierbare Fehler nehmen mit dem Alter ab. Korrigierbare Fehler nehmen ab einem Alter von 10 bis 18 Monaten zu.
  • DIMMs neuerer Generationen verhalten sich weder besser noch schlechter als ihre Vorgänger.
  • Die Temperatur hat einen verblüffend geringen Effekt.
  • Die Speicherfehlerraten korrelieren mit der Auslastung.

Linux und Speicherfehler

Der Autor dieses Beitrags arbeitete vor Jahren an einem Projekt namens Bluesmoke mit, das ein Kernel-Modul schaffen wollte, das Hardware-Fehler erkennen und melden sollte. Dabei ging es nicht allein um Speicherfehler, sondern um alle möglichen Fehler im Cache, beim DMA, bei der Temperaturregelung, auf dem Bus und so weiter. Der offizielle Name des Projekts war EDAC (Error Detection And Correction, siehe [5]).

Viele Jahre lang schrieben Enwickler EDAC-Module für die verschiedensten Chipsätze. Das geschah zunächst außerhalb des Kernels, aber seit Kernel 2.6.16 ist EDAC dort integriert. Seit 2.6.18 erscheint EDAC auch im Sys-Filesystem unter »/sys/devices/system/edac« .

Eine der besten Informationsquellen über EDAC ist das EDAC-Wiki [6]. Die Seite beschreibt den Einstieg und listet andere Ressourcen über EDAC (FAQs, Mailing-Listen und so weiter) auf. Hier soll es vor allem darum gehen, welche nützlichen Informtionen EDAC liefern kann. Für die Beispiele kommt ein Dell PowerEdge R720 zum Einsatz, der über zwei Prozessoren und 128 GByte Hauptspeicher verfügt. Während der Tests lief er unter CentOS 6.2.

Zunächst muss man sich vergewissern, dass die EDAC-Module geladen sind:

login2$ lsmod | grep edac
sb_edac                18104  0
edac_core              53053  1 sb_edac

Sind die Module geladen, kann man als Nächstes das Verzeichnis »/sys/devices/edac« untersuchen:

login2$ ls -s /sys/devices/system/edac
insgesamt 0
0 mc

Wenn hier nur das device »mc« auftaucht, überwacht EDAC nur den Memory-Controller. Schaut man tiefer in die Verzeichnisstruktur

login2$ ls -s /sys/devices/system/edac/mc
insgesamt 0
0 mc0 0 mc1

kommen die beiden Komponenten »mc0« und »mc1« zum Vorschein. Listing 1 zeigt, was man sieht, wenn man in das Verzeichnis »mc0« schaut.

Listing 1

Memory-Controller

login2$ ls -s /sys/devices/system/edac/mc/mc0
total 0
0 ce_count         0 csrow1  0 csrow4  0 csrow7   0 reset_counters       0 size_mb
0 ce_noinfo_count  0 csrow2  0 csrow5  0 device   0 sdram_scrub_rate     0 ue_count
0 csrow0           0 csrow3  0 csrow6  0 mc_name  0 seconds_since_reset  0 ue_noinfo_count

Die beiden Memory-Controller dieses Systems verwalten eine Reihe von DIMMs, die in Zeilen (Chip Select, »csrow« ) und einer Kanaltabelle (»chx« ) organisiert sind (mehr Details dazu in der EDAC-Dokumenttion [7]). Wie Listing 2 zeigt, kann es mehrere Csrows und mehrere Channels geben. Ihre Anzahl hängt vom Motherboard und der Art der Speicher-Controller und DIMMs ab.

Listing 2

Csrows und Channels

 

Ein Beispiel

Für dieses Beispiel hat jeder Memory-Controller acht Csrows und eine Kanaltabelle. Eine Vorstellung vom Layout vermittelt Listing 3.

Listing 3

Memory-Controller-Layout

login2$ more /sys/devices/system/edac/mc/mc0/csrow0/ch0_dimm_label
CPU_SrcID#0_Channel#0_DIMM#0
login2$ more /sys/devices/system/edac/mc/mc0/csrow1/ch0_dimm_label
CPU_SrcID#0_Channel#0_DIMM#1
login2$ more /sys/devices/system/edac/mc/mc0/csrow2/ch0_dimm_label
CPU_SrcID#0_Channel#1_DIMM#0
login2$ more /sys/devices/system/edac/mc/mc0/csrow3/ch0_dimm_label
CPU_SrcID#0_Channel#1_DIMM#1
login2$ more /sys/devices/system/edac/mc/mc0/csrow4/ch0_dimm_label
CPU_SrcID#0_Channel#2_DIMM#0
login2$ more /sys/devices/system/edac/mc/mc0/csrow5/ch0_dimm_label
CPU_SrcID#0_Channel#2_DIMM#1
login2$ more /sys/devices/system/edac/mc/mc0/csrow6/ch0_dimm_label
CPU_SrcID#0_Channel#3_DIMM#0
login2$ more /sys/devices/system/edac/mc/mc0/csrow7/ch0_dimm_label
CPU_SrcID#0_Channel#3_DIMM#1

Im Beispiel verfügt jeder Kanal (0 und 1) über vier Speicherkanäle (0 bis 3) und zwei DIMMs pro Kanal (0 und 1). In jedem »csrow« -Unterverzeichnis finden sich dann eine Reihe weiterer Control- und Attribut-Files mit folgender Bedeutung:

  • ce_count: Die Gesamtzahl korrigierbarer Fehler (correctable errors, ce) in dieser Csrow.
  • ch0_ce_count: Die Gesamtzahl korrigierbarer Fehler auf diesem DIMM in Kanal 0.
  • ch0_dimm_label: Label des DIMM. Das kann sehr nützlich sein, um nach einer Kernel Panic die Ursache des nicht korrigierbaren Fehlers zu finden. Die DIMM-Labels sollten nach dem Booten zugewiesen werden und Informationen enthalten, die zu dem physischen Slot führen.
  • dev_type: Attribut-File, das Informationen über den Typ des DIMM enthält. Der Wert ist typischerweise x1, x2, x4 oder x8.
  • edac_mode: Attribut-File, das den Typ der Fehlererkennung und -korrektur enthält.
  • mem_type: Enthält den Speichertyp einer Csrow.
  • size_mb: Attribut-File, das die Größe des Memorys in einer Csrow enthält.
  • ue_cont: Enthält die Gesamtzahl nicht korrigierbarer Fehler, die in einer Csrow aufgetreten sind.

Einige Attribut-Files in »/sys/devices/system/edac/mc/mc0« können sehr nützlich sein. Sie beziehen sich auf den gesamten Controller:

  • ce_count: Die Gesamtzahl korrigierbarer Fehler dieses Controllers.
  • ce_noinfo_count: Die Gesamtzahl korrigierbarer Fehler, aber ohne Information, welchen DIMM-Slot sie betroffen haben.
  • mc_name: Der Typ des benutzten Memory-Controllers.
  • reset_counters: Ein nur beschreibbares Kontroll-File, das alle Fehler-Zähler dieses Memory-Controllers zurücksetzt. Das passiert, sobald man einen Wert in das File schreibt.
  • sdram_scrub_rate: Ein Attribut-File für die Speicherreinigung. Der enthaltene Wert repräsentiert eine Rate in Bytes pro Sekunde.
  • seconds_since_reset: Anzahl der Sekunden seit dem letzten Zähler-Reset.
  • size_mb: Menge des Speichers, den dieser Controller verwaltet.
  • ue_count und ue_noinfo_count: Wie oben, hier aber pro Controller.

Die Werte des Beispielsystems zeigt Listings 4 und 5. Der letzte Reset liegt demnach 27 759 752 Sekunden oder ungefähr 321 Tage zurück. Der Speicher-Controller verwaltet 64 GByte und es gab weder korrigierbare noch nicht korrigierbare Fehler.

Listing 4

mc0/csrow0

login2$ ls -s /sys/devices/system/edac/mc/mc0/csrow0
total 0
0 ce_count      0 ch0_dimm_label  0 edac_mode  0 size_mb
0 ch0_ce_count  0 dev_type        0 mem_type   0 ue_count

Listing 5

Werte des Beispielsytems

login2$ more /sys/devices/system/edac/mc/mc0/ce_count
0
login2$ more /sys/devices/system/edac/mc/mc0/ce_noinfo_count
0
login2$ more /sys/devices/system/edac/mc/mc0/mc_name
Sandy Bridge Socket#0
login2$ more /sys/devices/system/edac/mc/mc0/reset_counters
/sys/devices/system/edac/mc/mc0/reset_counters: Permission denied
login2$ more /sys/devices/system/edac/mc/mc0/sdram_scrub_rate
login2$ more /sys/devices/system/edac/mc/mc0/seconds_since_reset
27759752
login2$ more /sys/devices/system/edac/mc/mc0/size_mb
65536
login2$ more /sys/devices/system/edac/mc/mc0/ue_count
0
login2$ more /sys/devices/system/edac/mc/mc0/ue_noinfo_count
0

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019