So testen Sie RAM auf QNAP-Servern richtig mit MemHound

Das Testen von RAM in einem aktiven Betriebssystem (Userspace) ist eine technische Herausforderung. Das Betriebssystem, Virtualisierungs- und Caching-Dienste (vor allem ZFS ARC) reservieren ständig Adressraum und blockieren den Zugriff darauf.

MemHound, das Memory Doctor-Fenster der StorageDiag Workbench, arbeitet sich über eine Eskalationsleiter hoch: Quick → Standard → Deep → Hammer → Boot. Es sperrt den gesamten freien RAM, den es belegen darf, abzüglich einer Reserve von 256 MB, schreibt Testmuster hinein, liest sie wieder aus und hält jeden Block bis zum Ende des Durchlaufs fest, sodass der Kernel jede freie Seite herausgeben muss. Nachfolgend erfahren Sie, wie Sie die Speicherstabilität für Ihre Konfiguration und Ihr Dateisystem überprüfen.

1. Quickschneller Durchlauf, das NAS arbeitet weiter
2. StandardMoving Inversions, das NAS arbeitet weiter
3. Deepstoppt Dienste, gibt den ARC frei
4. HammerRow-Hammer auf jedem Kern
5. Bootder USB-Stick, außerhalb des NAS-Systems

01Tägliche Diagnose unter QTS (ext4)

Mit einem traditionellen Dateisystem (ext4) reserviert QTS keine großen Mengen an RAM für sich selbst, deshalb gelingt ein zuverlässiger Test im laufenden System leichter. Speicherfehler zeigen sich oft im Userspace, daher sind regelmäßige Quick-Tests wirksam.

1. Schalten Sie nicht zwingend benötigte Netzwerkdienste aus (Samba, NFS, AFP).
2. Stoppen Sie die ressourcenintensiven Apps im App Center (HDMI-Desktopstationen, Container, virtuelle Maschinen) und lassen Sie nur StorageDiag laufen. Lassen Sie nur einen einzigen Browser-Tab mit dem NAS geöffnet.
3. Bei geleerten Caches und gestoppten Diensten steht der Großteil des physischen RAM für den Test zur Verfügung. Die Karte „Quick“ erhält die Kennzeichnung DAILY, wenn mindestens 90 % des RAM frei sind.
4. Führen Sie den Test Quick aus. Er ist schnell, weil er nach einer Adressprüfung zwei Muster ausführt und den Cache nicht nach jeder Zeile leert, wie es der Standard-Test tut. Stellen Sie 1 bis 3 Durchläufe ein (im Feld Passes sind 1 bis 16 möglich, voreingestellt ist 1). Wenn der erreichte Speicher einen Hardwarefehler aufweist, findet der Test ihn fast sofort.

02Diagnose unter QuTS hero (ZFS)

Das ZFS-Dateisystem verwendet den ARC (Adaptive Replacement Cache), der den größten Teil des verfügbaren RAM belegen kann. In diesem Fall deckt ein einfacher Quick-Test nur einen Bruchteil des Speichers ab.

1. Wählen Sie anstelle von Quick den Test Deep.
2. Nach Ihrer Bestätigung (Stop services & test) stoppt MemHound die NAS-Dienste und die Apps im App Center (das Webpanel bleibt aktiv), leert den ZFS ARC und verwirft die Kernel-Caches. Dadurch wird der größte Teil des physischen Speichers für den Test freigegeben: Auf einem TS-1288X mit 128 GB stieg der verfügbare Speicher von 96,6 GB auf 116,9 GB.
3. Ablauf: Zunächst wird ein Quick-Durchlauf über den freigegebenen RAM ausgeführt. Findet er Fehler, endet der Vorgang vorzeitig und spart Zeit. Werden keine Fehler gefunden, fährt das Tool mit dem Standard-Durchlauf fort.
4. Ausfallzeit: Die Dienste sind nicht verfügbar, solange sie gestoppt werden und solange beide Durchläufe laufen. Ein Standard-Durchlauf über viel RAM kann Stunden dauern. Die Dienste starten automatisch neu, wenn der Test endet, wenn Sie ihn abbrechen, wenn der Testprozess unerwartet beendet wird und spätestens zwei Stunden nach dem Start. Dauert allein das Stoppen der Dienste länger als 30 Minuten, wird der Test abgebrochen und alles wiederhergestellt.

03Absolutes Testen (Rescue-Modus / offline)

Wenn das Kernel-Protokoll (klog) auf instabilen Speicher hinweist (spontane Segfaults in verschiedenen Programmen, Call Traces, Machine Checks oder EDAC-Fehler), die Tests aus dem laufenden System (Quick, Deep) aber mit PASS enden, wechseln Sie in eine isolierte Umgebung. Sie umgeht das NAS-Betriebssystem vollständig.

Option A: Ein bootfähiger USB-Stick (empfohlen)

Der USB-Stick wurde so konzipiert, dass der gesamte Test von selbst abläuft, auch auf Geräten, an die Sie keinen Monitor und keine Tastatur anschließen können. Es ist kein Tastendruck erforderlich. Der Boot-Eintrag macht den Stick beim nächsten Neustart zur Standardauswahl, der Test startet von allein und meldet seinen Fortschritt unter der eigenen Adresse des NAS, die das MemHound-Fenster für Sie einliest. Nach einem PASS startet das NAS von selbst wieder in QTS und das Fenster zeigt das Ergebnis an; bei einem Speicherfehler schaltet der Test das NAS aus (siehe unten). Ein Monitor und eine Tastatur werden nur benötigt, wenn die Firmware den Boot-Eintrag nicht übernehmen kann und der Stick aus dem Boot-Menü des Geräts gestartet werden muss.

1. Klicken Sie im MemHound-Fenster in der Titelleiste auf Create bootable USB.
2. Stecken Sie einen beliebigen USB-Stick mit mehr als 192 MB in einen USB-Port des QNAP. Alles darauf wird gelöscht, die aktuelle Formatierung spielt keine Rolle.
3. Klicken Sie auf Update the image, wenn der Assistent einen neueren Build anbietet (beim ersten Mal auf Download the image), und folgen Sie dann den Anweisungen: Continue, Gerätenamen eingeben, Erase and write, Add the boot entry.
4. Starten Sie den Server vom vorbereiteten Diagnose-Stick neu (Restart now and test). Wenn das NAS wieder läuft, zeigt das Fenster das Ergebnis an.

Wenn der Test beim Booten nicht wie geplant abläuft

• Das NAS startet den Test nicht vom Stick. Add the boot entry legt eine Datei, grub/custom.cfg, auf der eigenen Boot-Partition des NAS ab. Beim Einschalten sucht der Bootloader des NAS (GRUB) nach einem Volume mit der Bezeichnung MEMHOUND und startet es, wenn er eines findet. GRUB sieht einen USB-Stick nur durch die eigene USB-Unterstützung der Firmware. Daher bootet das NAS wie gewohnt QTS, wenn die Firmware den Stick beim Einschalten nicht anbietet (bei einigen billigen oder qualitativ minderwertigen Sticks der Fall), wenn das USB-Booten im Firmware-Setup deaktiviert ist oder aus einem von der Firmware nicht angezeigten Grund. Versuchen Sie einen anderen Stick, einen USB-Port auf der Rückseite oder starten Sie den Stick aus dem Boot-Menü des Geräts (F11 oder die Taste, die dieses Modell verwendet, beim Einschalten). Der Assistent meldet This firmware cannot be given a boot entry, wenn der Bootloader die Datei gar nicht liest, und The boot entry here is an old one, wenn eine frühere Version sie geschrieben hat (Replace the boot entry). Ein Stick, dessen Test bereits gelaufen ist, wird nicht noch einmal gestartet: Beschreiben Sie ihn erneut mit Create bootable USB, um noch einmal zu testen.
• Das NAS hat sich selbst ausgeschaltet und ist nicht wieder hochgefahren. Das macht der Test, wenn er einen Speicherfehler findet: Er schaltet das NAS absichtlich ab, damit bei diesem Speicherzustand nichts auf die Festplatten geschrieben wird, und er startet es nicht neu. Ein bestandener Test bootet das NAS stattdessen neu in QTS. Ein NAS, das sich während des Boot-Tests ausgeschaltet hat und aus geblieben ist, weist daher auf einen Speicherfehler hin. Die Details finden Sie auf dem Stick (FAT32, Bezeichnung MEMHOUND): Lesen Sie /memhound/report-<time>.txt und map-<time>.json auf einem beliebigen Computer oder stecken Sie den Stick in ein intaktes NAS, auf dem die StorageDiag Workbench läuft, und öffnen Sie MemHound, das ihn von selbst einliest.

Option B: Rescue-Modus (ohne konfigurierte Festplatten) über SSH

Wenn Sie lieber remote arbeiten und die Grundlagen der Kommandozeile kennen, bietet dieser Modus einen vollständigen Test ohne USB-Stick.

1. Melden Sie sich über SSH am QNAP-Server an.
2. Wählen Sie im Textmenü (QTS Console Management) die Option, den Server im Rescue-Modus neu zu starten (ohne konfigurierte Festplatten).
3. Nach dem Neustart findet Qfinder den Server als „uninitialized“ (nicht initialisiert). Das ist zu erwarten.
4. Aktivieren Sie SSH über Qfinder. Melden Sie sich als admin an (unter QTS 5.2 und neuer ist das Standardpasswort das Cloud-Passwort; in älteren Versionen ist es die vollständige MAC-Adresse in Großbuchstaben ohne Doppelpunkte).
5. Laden Sie MemHound mit dem ersten Block unten herunter und entpacken Sie es. Mit dem zweiten Block starten Sie dann die Tests im Textmodus.

# MemHound herunterladen und entpacken
arch=$(uname -m)
[ "$arch" = armv7l ] && arch=armhf
wget https://www.qnaputilities.com/pub/memhound/bin/memhound.tar.gz
tar zxvf memhound.tar.gz
chmod +x memhound-*

# Quick-Test mit 2 Durchläufen (empfohlener Ausgangspunkt)
./memhound-$arch --quick --passes 2 --ui

# Standard-Test (nach einem Quick PASS mit End reason : completed)
./memhound-$arch --standard --ui

Quick überprüft zuerst die Adressen und schreibt dann ein Schachbrettmuster und eine zufällige Moving Inversion. Standard wiederholt diese beiden Muster und fügt elf weitere hinzu, alles in einem Durchlauf, und führt einen Durchgang aus, es sei denn, Sie fügen --passes hinzu. Wenn die Text-Benutzeroberfläche geschlossen wird, gibt MemHound eine Zusammenfassung auf Englisch aus. Fahren Sie mit Standard fort, wenn dort Verdict : PASS und End reason : completed steht: Ein durch Speichermangel abgebrochener Durchlauf meldet immer noch PASS, mit End reason : aborted: …. Abschnitt 04 erläutert die anderen Ergebnisse.

04So lesen Sie die Ergebnisse

MemHound entscheidet nach festen Regeln, und die Regeln hängen vom Test ab. Quick, Standard, Deep und Hammer suchen in dem von ihnen erreichten Speicher nach Fehlern. Benchmark and Quality (weiter unten) bewertet dagegen ein komplettes Speicher-Kit.

Quick, Standard, Deep und Hammer

• Harte und vorübergehende Fehler. Ein einziger fehlerhafter Lesevorgang verurteilt noch kein Modul. MemHound wertet ihn als vorübergehend: Die Karte markiert ihn als Suspect und die Textzusammenfassung meldet PASS_WITH_TRANSIENTS. Ein Fehler wird hart, wenn eine spätere Prüfung an derselben Adresse des eigenen Speichers von MemHound (der virtuellen Adresse; die physische wird daneben als p= ausgegeben) erneut fehlschlägt, standardmäßig nach zwei Treffern (--hard-threshold 2). Jeder harte Fehler führt zum Ergebnis FAIL.
• Was das Workbench-Fenster sagt. Die Statuszeile zählt beide Arten, zum Beispiel FAIL — 0 hard fault(s), 1 transient. Wenn kein harter Fehler vorliegt, wiederholen Sie den Test offline (über den Stick oder den Rescue-Modus), bevor Sie ein Modul verantwortlich machen: Die Anleitung in der App wertet ein Ergebnis mit nur vorübergehenden Fehlern als Grund für einen erneuten Test offline, nie als Grund für eine RMA (Rücksendung). Die Textzusammenfassung ergänzt, dass solche Ergebnisse auf Probleme mit der Stromversorgung, der Wärme oder knappen Timings hindeuten können.
• ECC-Zähler und das Kernel-Protokoll. Die ECC-Zähler (EDAC) und die Kernel-Log-Ereignisse werden neben dem Ergebnis angezeigt, und die Zusammenfassung fügt <== HARDWARE ECC ERRORS DURING TEST hinzu, wenn ein Zähler gestiegen ist. Sie ändern das Ergebnis nicht; prüfen Sie sie deshalb selbst.
• Wie der Durchlauf endete. Die Zusammenfassung endet mit End reason: completed, stopped by user oder aborted: …. Ein Durchlauf, der nicht mit completed endete, hat nicht alles getestet, was er sich vorgenommen hatte, ganz gleich, was in der Ergebniszeile steht.

Gut zu wissen: Benchmark und Quality

Die Schaltfläche Benchmark and Quality in der Titelleiste von MemHound misst die anhaltende Speicherbandbreite im Vergleich zum JEDEC-Wert der installierten Module, prüft Latenzschwankungen (Jitter) und schlägt bei jedem Bitfehler fehl. Ihr Ergebnis ist PASS (oder PASS-UNQUALIFIED), MARGINAL, FAIL oder INCONCLUSIVE, und ihre Regeln sind strenger als die der Fehlersuche.

• Fehler. Ein Bitfehler, ein unkorrigierter ECC-Fehler (UE) oder ein kritisches Kernel-Ereignis, das während des Durchlaufs protokolliert wurde, führt zum Ergebnis FAIL. Kritische Ereignisse sind ein Machine Check oder „Hardware Error“, ein unkorrigierter Speicherfehler, ein Speicherausfall, Datenkorruption oder ein Kernel Panic. Ein korrigierter ECC-Fehler (CE) begrenzt das Ergebnis auf höchstens MARGINAL: Das Modul funktioniert, aber das Kit kann nicht zertifiziert werden. Segfaults, Call Traces, Oops und OOM Kills werden angezeigt, ändern das Ergebnis aber nicht.
• Ein abgestimmtes Kit. Der Test bewertet genau ein abgestimmtes Kit (Matched Kit). Seine Eingangsprüfung (Gate) schlägt fehl, wenn sich die Module unterscheiden (nach Teilenummer, oder nach Größe, Geschwindigkeit, Typ und ECC, wenn DMI die Teilenummer nicht liefert), wenn 3 Module oder eine ungerade Anzahl über 4 vorhanden sind, oder wenn die Kanäle A und B unterschiedlich viel Speicher haben. Der Lauf wird zur Information fortgesetzt, aber das Ergebnis ist FAIL, und das Resultat wird weder gespeichert noch geteilt. Wenn DMI nichts meldet, entfällt das Gate.
• Ein ausgelastetes NAS. Fällt die Bandbreite zu niedrig aus (FAIL oder MARGINAL) oder scheitert die Prüfung der Latenzschwankungen, während das NAS ausgelastet ist (Last im 1-Minuten-Mittel über 0,6 pro CPU), zu wenig freien Speicher hat (unter 40 % zu Beginn) oder gedrosselt läuft, lautet das Ergebnis INCONCLUSIVE: Der Zustand des Systems ist schuld, nicht die Module. Ein von Ihnen oder vom Speicherschutz gestoppter Durchlauf ist ebenfalls INCONCLUSIVE. Bitfehler, UE, kritische Kernelereignisse, Musterfehler, Bit Fades und das Kit-Gate werden auf diese Weise niemals abgemildert.

05RAM in einem NAS, bewährte Praktiken und Hardware-Eigenheiten

Bevor Sie den Festplatten oder dem Netzwerk die Schuld an langsamen Übertragungen geben, sollten Sie wissen, was Speicher in einem NAS besonders macht. NAS-Speicher ist kein Gaming-PC-Speicher. Ein NAS läuft rund um die Uhr unter einer konstanten Last: Systempuffer, der ZFS-Cache (ARC), virtuelle Maschinen und Container. Was es vom Speicher verlangt, ist Stabilität und Kompatibilität, keine Rekordtaktraten. Außerdem verzeiht es Fehler weniger als ein Desktop-PC: Lange Betriebszeiten und eine konstante Last bringen seltene Fehler ans Licht, die häufige Neustarts auf einem PC verbergen würden.

Auf einer Plattform ohne ECC (z. B. einem TS-464) lässt sich ECC durch keine Einstellung aktivieren. UDIMMs sind ungepuffert; RDIMMs und LRDIMMs sind registered (registriert) und entlasten den Controller, sodass ein Kanal mehr Module mit großer Kapazität aufnehmen kann.

Können drei Module langsamer sein als zwei? Ja, vor allem auf AMD. Ein Ryzen-Speichercontroller senkt seinen garantierten Takt mit der Anzahl der Module und Ranks pro Kanal: DDR4 3200 bei einem Modul pro Kanal, 2933 bei zwei Single-Rank-Modulen, 2666 bei zwei Dual-Rank-Modulen. Mehr Module bringen mehr Kapazität, aber weniger Bandbreite. Wird für eine Aufgabe der Speicher knapp, ist mehr Kapazität trotzdem besser, als wenn der Speicher ganz ausgeht und das System auslagern muss (Swapping).