ECC-Arbeitsspeicher

Normaler Arbeitsspeicher sagt nie Bescheid, wenn er sich bei einem Bit vertan hat. ECC-Speicher hebt wenigstens die Hand.

Kurz gesagt

ECC-Speicher legt neben deinen Daten ein paar zusätzliche Prüfbits ab. Der Speichercontroller erkennt damit ein gekipptes Bit und repariert es im Normalfall, bevor deine Software etwas davon merkt [13][14]. Ob du ECC brauchst, hängt davon ab, was auf der Maschine liegt und was ein unbemerkter Fehler kosten würde. Unsere Einschätzung: Ein Dateiserver, ein Hypervisor oder ein Datenbankhost ist ein guter Kandidat, ein Wegwerf-Testrechner nicht.

So funktioniert’s

1. Zusätzliche Prüfbits und SECDED. ECC steht für „Error-Correcting Code“, also fehlerkorrigierender Code. Bei DDR3 und DDR4 ist ein ECC-Modul 72 statt 64 Bit breit, weil es zusätzliche DRAM-Chips für die Prüfbits trägt [11]. Die Linux-Kernel-Dokumentation beschreibt dasselbe Layout: 64 Datenbits plus 8 Bit ECC-Daten [1]. Bei DDR5 ist es anders. Dort ist ein Modul in zwei Unterkanäle mit je 32 Bit geteilt, und Kingston nennt zwei ECC-Breiten: 72 Bit (EC4) und 80 Bit (EC8) [11]. Kingstons DDR5-Übersicht beschreibt die 80-Bit-Anordnung für Server-RDIMMs, mit 8 zusätzlichen Bits je Unterkanal [21], und Microns Referenzübersicht führt DDR5-RDIMMs mit x80 [12]. Verwechsle das nicht mit On-Die-ECC. DDR5-Chips korrigieren manche Bitfehler im Chip selbst, laut Kingston aber keine Fehler außerhalb des Chips oder auf dem Weg zum Speichercontroller im Prozessor [21]. Das ECC, um das es in diesem Artikel geht, braucht die zusätzliche Breite eines ECC-Moduls und einen Controller, der sie nutzt. Steht im Datenblatt „DDR5 mit On-Die-ECC“, ist das Modul deshalb noch kein ECC-Modul. Der Controller berechnet die Prüfbits beim Schreiben, berechnet sie beim Lesen neu und vergleicht beide [14]. Der klassische Code heißt SECDED: Er korrigiert jedes einzelne gekippte Bit in einem Datenwort und erkennt jedes Paar gekippter Bits [13]. Stärkere Verfahren gibt es auch. Der Kernel führt „Chipkill“-Modi auf, die den Ausfall eines ganzen DRAM-Chips überstehen [1]. Eine Cisco-Technikschrift für Server beschreibt dieselbe Idee unter dem Namen „Single Device Data Correction“ [13].
2. Korrigierbare und unkorrigierbare Fehler. Ein korrigierbarer Fehler (CE) ist einer, den der Code behoben hat. Ein unkorrigierbarer Fehler (UE) ist einer, den ECC nicht beheben konnte [1]. Der Kernel kennt zwei weitere Stufen, „deferred“ und „fatal“, für nicht dringende und für nicht behebbare Fehler [1]. Laut Kernel-Dokumentation ist ein wachsender CE-Zähler ein frühes Zeichen dafür, dass ein DIMM zu versagen beginnt [2]. Für UEs gibt es die Einstellung panic_on_ue, die das System anhält, statt mit falschen Daten weiterzumachen [2].
3. ECC ist nicht dasselbe wie „registered“. Hier werden zwei Fragen gern vermischt. Die Pufferung fragt, ob zwischen DRAM und Speichercontroller ein Register-Baustein sitzt: registered (RDIMM) oder unbuffered (UDIMM) [12]. ECC fragt, ob das Modul zusätzliche Breite für Prüfbits hat: 72 statt 64 Bit bei DDR3 und DDR4, 72 (EC4) oder 80 Bit (EC8) bei DDR5 [11]. Unbuffered-Module gibt es mit und ohne ECC [11][12]. Registered- und Unbuffered-Module lassen sich nicht mischen, und bei DDR5 sitzen die Kerben anders, sodass sie gar nicht in denselben Steckplatz passen [11]. Ein Punkt ist unklar. Stand 18. Okt. 2026 beschreibt Kingston RDIMMs als ECC-fähige Module [11], während Microns aktuelle Referenzübersicht RDIMMs mit „ECC und Non-ECC unterstützt“ aufführt [12]. Lies deshalb Teilenummer und Datenblatt, statt vom Namen auf die Fähigkeit zu schließen.
4. Was Feldstudien zeigen. Die bekannteste Studie ist „DRAM Errors in the Wild“ von Schroeder, Pinheiro und Weber. Sie deckt Googles Serverflotte von Januar 2006 bis Juni 2008 ab, mit DDR1-, DDR2- und FB-DIMM-Speicher [3]. Etwa ein Drittel aller Maschinen und über 8 Prozent der einzelnen DIMMs sahen pro Jahr mindestens einen korrigierbaren Fehler [3]. Unkorrigierbare Fehler trafen pro Jahr 1,3 Prozent der Maschinen und 0,22 Prozent der DIMMs [3]. Fehler treten gehäuft auf: Ein DIMM mit einem korrigierbaren Fehler hatte im selben Monat eine 13- bis 228-fach höhere Wahrscheinlichkeit für einen weiteren [3]. Den meisten unkorrigierbaren Fehlern gingen korrigierbare voraus, auch wenn die Chance auf einen unkorrigierbaren Fehler nach einem korrigierbaren bei nur 0,1 bis 2,3 Prozent pro Monat lag [3]. Die Autoren fanden starke Hinweise auf Hardwarefehler, also wiederkehrende Defekte, und nicht auf zufällige Softfehler [3][4]. Eine Folgestudie von Hwang, Stefanovici und Schroeder zeichnet ein ähnliches Bild: In allen untersuchten Systemen zeigten mehr als ein Drittel der Speicherbänke mit Fehlern Anzeichen von Hardwarefehlern [5].
5. Wie weit die Zahlen tragen. Hier ist Vorsicht nötig. Es sind Ergebnisse aus Rechenzentren mit alten Speichergenerationen. Der Anteil der DIMMs mit korrigierbaren Fehlern lag je nach Plattform zwischen etwa 3 und etwa 20 Prozent [3]. In unserer Recherche haben wir keine vergleichbare Primärstudie für Heim-Hardware gefunden. Du kannst diese Prozentwerte deshalb nicht als dein eigenes Risiko lesen. Sie zeigen, dass Speicherfehler kein theoretisches Problem sind. Sie sagen nicht, wie wahrscheinlich einer in deiner Maschine ist.
6. Wann sich ECC lohnt. Die OpenZFS-Dokumentation sagt, dass keine Technik eines Dateisystems vor Bitkippern schützt, und empfiehlt ECC-Speicher deshalb nachdrücklich [17]. Die FAQ ist gelassener: ECC ist keine Pflicht, und für Heimanwender rechtfertigt der Zusatzschutz die Kosten womöglich nicht [18]. Wir sehen beides so. Unsere Einschätzung: ECC lohnt sich dort, wo ein falsches Bit teuer ist und niemand es bemerken würde. Das sind Dateiserver, ZFS-Systeme, Hypervisor mit vielen virtuellen Maschinen und Datenbanken. Weniger dringlich ist es bei einer Maschine, deren Daten ersetzbar, gesichert und ohnehin geprüft sind. ECC ersetzt kein Backup. Es schließt nur eine Lücke.
7. Was du dafür brauchst. Drei Teile müssen zusammenpassen: Prozessor, Board und Modul. Intel schreibt, dass ECC-Unterstützung Prozessor und Chipsatz voraussetzt, und veröffentlicht je Prozessor ein Ja/Nein-Feld namens „ECC Memory Supported“ [10]. Bei AMD nennt die Chipsatz-Seite ECC-Unterstützung für die Threadripper-Plattformen und sagt zur Plattform AM4, dass die Prozessorunterstützung je Chipsatz verschieden ist und der Boardhersteller die Einzelheiten kennt [20]. Eine Liste eines Boardherstellers nennt für Ryzen-Prozessoren mit Grafikeinheit nur die PRO-Modelle als ECC-fähig [19]. Dazu muss die Firmware mitspielen: Kingston nennt Prozessor und BIOS als Voraussetzung, um die Funktion zu nutzen [11]. Prüfe daher auch im BIOS oder UEFI, ob es eine ECC-Option gibt. Server-Firmware hat oft ein eigenes Menü für den Speicherschutz, etwa bei HPE ProLiant Gen10 [15].
8. EDAC lesen und das Firmware-Log. EDAC ist das Linux-Kernel-Subsystem, das Fehler des Speichercontrollers meldet [1]. Es legt Zähler unter /sys/devices/system/edac/mc/ ab: je Controller ce_count und ue_count, dazu ce_noinfo_count und ue_noinfo_count für Fehler ohne bekannten DIMM-Steckplatz, und je DIMM dimm_ce_count, dimm_ue_count und dimm_edac_mode [2]. Laut rasdaemon-Projekt decken die EDAC-Treiber die meisten Chipsätze auf x86 ab [6], und das Projekt edac-utils lädt den passenden Treiber zum Chipsatz [8]. Unsere Einschätzung: Ein leeres Verzeichnis mc beweist deshalb nicht, dass ECC fehlt. Es kann nur heißen, dass kein Treiber geladen ist. Zwei Werkzeuge lesen die Daten aus. edac-util liest die sysfs-Dateien und schreibt „No errors to report.“, wenn nichts gezählt wurde [9]. rasdaemon protokolliert die Fehlerereignisse des Kernels in syslog oder journald und kann sie mit --record in einer Datenbank speichern; ras-mc-ctl zeigt dann Zusammenfassungen, Fehler, das erkannte Layout und die sysfs-Zählerstände [6][7]. Server-Firmware führt ein eigenes Protokoll. Auf HPE-ProLiant-Servern kann das Integrated Management Log (IML) einen Eintrag „Correctable Memory Error Threshold Exceeded“ enthalten [16]. HPE hat außerdem einen Kundenhinweis veröffentlicht, dessen Titel besagt, dass Gen10-BIOS-Versionen Schwellenereignisse korrigierter Speicherfehler fälschlich in das IML schreiben können [16]. Wir kennen nur den Titel, nicht den Text des Hinweises; lies ihn auf der HPE-Supportseite, bevor du wegen eines solchen Eintrags ein DIMM tauschst. Unsere Einschätzung: Wenn Zähler des Betriebssystems und Firmware-Log nicht übereinstimmen, schau dir beide an, bevor du Ersatz kaufst.

Ein Homelab-Beispiel

Das Bytearium-Homelab betreibt Rackserver (HPE ProLiant DL360 Gen9 und DL380 Gen10), Stand 14. bis 18.10.2026. Über deren Speicherbestückung, ECC-Fähigkeit oder Speicherfehler haben wir nichts erfasst und sagen deshalb nichts dazu. Was folgt, ist ein allgemeiner Ablauf für deinen eigenen Linux-Server und kein Bericht über unsere. Als Beispiel prüfst du zuerst, ob der Kernel überhaupt einen Speichercontroller anzeigt: ls /sys/devices/system/edac/mc/. Siehst du ein Verzeichnis wie mc0, lies seine Zähler: cat /sys/devices/system/edac/mc/mc0/ce_count und cat /sys/devices/system/edac/mc/mc0/ue_count [2]. Die Dateien mc_name und size_mb im selben Verzeichnis nennen dir, welcher Controller meldet und wie viel Speicher er verwaltet [2]. Schau in mc0 nach DIMM-Verzeichnissen, die dimm_edac_mode enthalten [2]. Hast du die Werkzeuge installiert, zeigt edac-util -s, ob EDAC-Treiber geladen sind [9], und ras-mc-ctl --status sowie --layout zeigen den Treiberzustand und das erkannte Speicherlayout [7]. Zähler auf null heißen „seit dem Start nichts gezählt“, nicht „nie etwas passiert“. Ein Wert über null bei ce_count ist ein Grund, genauer hinzusehen, aber kein Grund zur Panik. Vergleiche das Ergebnis auf einem Server mit Management-Firmware mit dessen Ereignisprotokoll.

Prüfliste

• Prüfe, ob dein Einsatz ein einzelnes unbemerkt gekipptes Bit verkraftet, und schreib auf, was es kosten würde.
• Prüfe, ob du getestete Backups hast, denn ECC ersetzt sie nicht.
• Prüfe, ob dein Prozessor auf der Spezifikationsseite des Herstellers ECC-Unterstützung nennt.
• Prüfe, ob die Dokumentation von Board und Chipsatz ECC-Module als unterstützt aufführt.
• Prüfe, ob das Modul zum Typ passt, unbuffered oder registered, nie gemischt, und ob sein Datenblatt ECC mit der zusätzlichen Breite nennt: x72 bei DDR3 und DDR4, x72 (EC4) oder x80 (EC8) bei DDR5. On-Die-ECC allein zählt nicht.
• Prüfe, ob dein BIOS oder UEFI eine ECC-Option zeigt und ob sie eingeschaltet ist.
• Prüfe, ob der Kernel nach dem Start einen Speichercontroller unter /sys/devices/system/edac/mc/ anzeigt.
• Lies ce_count und ue_count regelmäßig aus und vergleiche sie mit dem Ereignisprotokoll des Servers.
• Tausche oder stecke ein DIMM erst nach wiederholten Fehlern neu, und lies vorher den Herstellerhinweis zu deinem Modell.