Hardware-Stresstest unter Linux: CPU, RAM und Disk mit stress-ng und smartctl prüfen

Bevor produktive Dienste oder wichtige Daten auf ein System kommen, ob frisch gebauter Homeserver, gebrauchte CPU oder verdächtiges RAM-Modul, testen Sie CPU, RAM und Festplatte unter Volllast. Diese Anleitung zum Hardware-Stresstest unter Linux kombiniert stress-ng für CPU-, Memory- und I/O-Last, bonnie++ als Festplatten-Benchmark und smartctl (smartmontools) für SMART-Werte und Selbsttests.

Was ist ein Hardware-Stresstest und wozu brauchen Sie ihn?

Ein Stresstest belastet Komponenten stärker als der Alltag und macht so Schwachstellen sichtbar: defekte RAM-Riegel, instabile Übertaktungen, Überhitzung durch schlecht sitzende Kühler oder Festplatten mit wachsenden Fehlersektoren zeigen sich oft erst nach Minuten am Limit.

stress-ng ist unter Linux der De-facto-Standard für synthetische Last auf CPU, Speicher und I/O. memtester prüft den RAM gezielt auf Bitfehler, bonnie++ liefert reproduzierbare Durchsatz- und IOPS-Werte, smartctl liest die SMART-Selbstdiagnose von SSDs und HDDs. Grundregel: Ein Crash unter Last deutet fast immer auf Überhitzung oder instabile Spannungsversorgung, ein reproduzierbarer Fehler (Bitfehler im RAM, wachsender Pending-Sector-Count) auf einen echten Hardwaredefekt.

Voraussetzungen

1. Ein Linux-System (Debian/Ubuntu, Fedora oder Arch) mit root- bzw. sudo-Rechten.
2. Terminalzugang, idealerweise zwei Sitzungen (Last und Monitoring) oder tmux.
3. Ausreichend Kühlung und stabile Stromversorgung; Notebooks am Netzteil testen.
4. Wichtig: Aktuelles Backup bei Schreibtests (bonnie++), denn Disk-Benchmarks erzeugen reale Schreiblast.
5. SMART-fähige SATA-, SAS- oder NVMe-Laufwerke (heute praktisch alle).
6. Zeit: 30 bis 60 Minuten normal, 8 Stunden oder mehr für kritische Fälle.
7. Hardware: Die Tools sind sparsam. Der RAM-Test braucht freien Arbeitsspeicher, bonnie++ freien Platz in doppelter RAM-Größe. Auf VPS und VMs testen Sie nur zugewiesene Ressourcen; Temperaturen und SMART-Werte fehlen dort meist.

Schritt 1: Tools installieren

Pakete installieren; lm-sensors liefert Temperatur- und Spannungswerte.

# Debian / Ubuntu
sudo apt update
sudo apt install -y stress-ng memtester bonnie++ smartmontools lm-sensors

# Fedora
sudo dnf install -y stress-ng memtester bonnie++ smartmontools lm_sensors

# Arch Linux (bonnie++ liegt dort nur im AUR)
sudo pacman -S --needed stress-ng memtester smartmontools lm_sensors

Sensoren einmalig initialisieren; --auto übernimmt die empfohlenen Antworten:

sudo sensors-detect --auto
sensors

Verifizieren: stress-ng --version und smartctl --version geben eine Versionsnummer aus, und sensors listet mindestens einen Temperaturwert für die CPU (z. B. Package id 0 oder Tctl).

Schritt 2: System-Baseline und CPU-Topologie ermitteln

Erfassen Sie vorab Kernzahl, RAM-Größe und Ruhetemperaturen als Vergleichsbasis.

# CPU-Kerne und Modell
lscpu | grep -E 'Model name|^CPU\(s\)|Thread'

# Verfügbarer Arbeitsspeicher
free -h

# Ruhetemperaturen ablesen
sensors

Notieren Sie die logischen Kerne (CPU(s)) und den freien Arbeitsspeicher, um die Last zu dimensionieren.

Verifizieren: Sie haben drei Werte notiert: die Zahl hinter CPU(s), den Wert in der Spalte available von free -h und die CPU-Temperatur im Leerlauf.

Schritt 3: Monitoring in einer zweiten Sitzung starten

Im zweiten Terminal oder tmux-Pane beobachten Sie die Temperaturen im Sekundentakt, während im ersten die Last läuft. Ohne Temperaturüberwachung verrät ein Absturz nicht, warum er passiert.

# Temperaturen jede Sekunde aktualisieren
watch -n 1 sensors

# Alternativ kombiniert mit Taktraten
watch -n 1 "sensors; echo; grep 'MHz' /proc/cpuinfo | head -n 8"

Faustregel: Desktop-CPUs sollten unter Dauerlast deutlich unter ihrer Throttling-Grenze (meist 90-100 Grad Celsius) bleiben. Taktet die CPU dort herunter, ist die Kühlung unterdimensioniert oder die Wärmeleitpaste schlecht aufgetragen.

Verifizieren: Die Ausgabe von watch -n 1 sensors aktualisiert sich jede Sekunde, die Kopfzeile zeigt Every 1.0s: sensors.

Schritt 4: CPU, RAM und I/O kombiniert stressen mit stress-ng

Der Befehl belastet vier CPU-Kerne mit zwei Speicher-Stressoren und zwei I/O-Workern. --cpu entspricht idealerweise den logischen Kernen aus Schritt 2.

# Kombinierter Stresstest über 60 Minuten
stress-ng --cpu 4 --vm 2 --io 2 --timeout 60m --metrics-brief

# Alle Kerne automatisch belegen (0 = alle CPUs)
stress-ng --cpu 0 --vm 1 --vm-bytes 80% --io 2 --timeout 60m --metrics-brief

Die Optionen:

1. --cpu N: N Worker mit Rechenlast.
2. --vm N: N Speicher-Worker; --vm-bytes ist die Gesamtmenge, aufgeteilt auf alle Worker. --vm 2 --vm-bytes 80% belegt zusammen rund 80 % des verfügbaren Speichers. Unter etwa 90 % bleiben, sonst drohen Swap oder OOM-Killer. Ohne --vm-bytes belegen die Worker nur 256 MB.
3. --io N: N Worker mit I/O-Last per sync().
4. --timeout 60m: Ende nach 60 Minuten; auch 30m, 8h usw.
5. --metrics-brief: kompakte Zusammenfassung am Ende.

Für maximale Wärmeentwicklung eignet sich die matrixprod-Methode:

stress-ng --cpu 0 --cpu-method matrixprod --timeout 30m --metrics-brief

Beobachten Sie dabei das Monitoring. Absturz oder Einfrieren sprechen stark für Überhitzung oder instabile Spannungsversorgung; bricht stress-ng mit Fehlermeldung ab, prüfen Sie die Ausgabe.

Verifizieren: Nach Ablauf der Zeit meldet stress-ng die Zeile successful run completed und der Exit-Code (echo $?) ist 0. Das System lief die ganze Zeit ohne Absturz durch.

Schritt 5: RAM gezielt auf Fehler testen

Die --vm-Last ist kein dedizierter Fehlertest. Für RAM-Fehler nutzen Sie memtester, das den Speicher mit bekannten Mustern beschreibt und zurückliest. Reservieren Sie weniger RAM, als verbaut ist, damit der Test nicht ins Swap läuft.

# 4096 MB Arbeitsspeicher in 1 Durchlauf prüfen
sudo memtester 4096M 1

# Mehrere Durchläufe für höhere Aussagekraft
sudo memtester 4096M 5

Jede Zeile sollte mit ok enden. FAILURE bedeutet sehr wahrscheinlich einen defekten Riegel oder ein Timing-Problem. Gründlicher, aber zeitaufwendiger ist ein Offline-Test mit Memtest86+ aus dem Bootmenü, der auch den vom Kernel belegten Bereich prüft.

Verifizieren: Die Ausgabe endet mit Done., jeder Einzeltest meldet ok, und echo $? liefert 0.

Schritt 6: SMART-Werte auslesen und Selbsttest starten mit smartctl

Vor der Plattenlast lesen Sie die SMART-Selbstdiagnose: Gerät ermitteln, Gesamtgesundheit prüfen.

# Verfügbare Laufwerke anzeigen
lsblk -d -o NAME,SIZE,MODEL

# Schnelle Gesundheitsbewertung
sudo smartctl -H /dev/sda

# Vollständige SMART-Attribute und Fehlerprotokoll
sudo smartctl -a /dev/sda

Bei SATA-Laufwerken achten Sie auf Reallocated_Sector_Ct, Current_Pending_Sector und Offline_Uncorrectable; Werte über null oder steigende Werte sind Warnsignale. Bei NVMe zeigen Critical Warning, Percentage Used und Media and Data Integrity Errors den Zustand. Dann den langen Selbsttest über die gesamte Oberfläche starten:

# Langen Selbsttest starten (läuft im Hintergrund des Laufwerks)
sudo smartctl -t long /dev/sda

# Geschätzte Laufzeit und Fortschritt abfragen
sudo smartctl -a /dev/sda | grep -A2 "Self-test execution"

# Nach Abschluss das Testprotokoll prüfen
sudo smartctl -l selftest /dev/sda

Er dauert je nach Größe mehrere Stunden und läuft im Laufwerk selbst, das Terminal kann zu. Ergebnis sollte Completed without error sein. NVMe: dieselben Befehle mit /dev/nvme0; Selbsttests brauchen ein unterstützendes Laufwerk und aktuelle smartmontools (ab 7.4 empfohlen).

Verifizieren: smartctl -H meldet PASSED (NVMe: SMART overall-health self-assessment test result: PASSED), und im Protokoll von smartctl -l selftest steht der jüngste Eintrag auf Completed without error.

Schritt 7: Festplatten-Benchmark mit bonnie++

Für reproduzierbare Durchsatz- und IOPS-Werte nutzen Sie bonnie++ mit Testverzeichnis auf dem Ziellaufwerk und einer Dateigröße über dem RAM-Cache (Faustregel: doppelter RAM), damit Sie die Platte messen und nicht den Cache.

# Testverzeichnis auf dem Ziellaufwerk anlegen
sudo mkdir -p /mnt/data/bonnie_test
sudo chown "$USER" /mnt/data/bonnie_test

# Benchmark mit 16 GB Testdaten ausführen
bonnie++ -d /mnt/data/bonnie_test -s 16G -n 0 -u "$USER"

-s 16G ist die Testdateigröße, -n 0 überspringt den Kleindatei-Test, -u gibt den Benutzer an, da bonnie++ nicht als root laufen will. Die Ausgabe zeigt sequenzielle Schreib-/Leseraten und Random-Seeks. Liegen sie deutlich unter den Herstellerangaben, prüfen Sie Kabel, SATA-Port oder SSD-Zustand. Danach aufräumen: sudo rm -r /mnt/data/bonnie_test.

Verifizieren: bonnie++ endet ohne Fehlermeldung und gibt am Schluss eine Ergebniszeile im CSV-Format aus. In der Tabelle darüber stehen Werte für Sequential Output und Sequential Input.

Schritt 8: Verifikation und Auswertung

Validiert ist ein System, wenn alles zutrifft:

1. stress-ng lief die gesamte Dauer ohne Absturz oder Einfrieren.
2. CPU-Temperatur unter der Throttling-Grenze, kein dauerhaftes Heruntertakten.
3. memtester meldete für jeden Durchlauf ok ohne FAILURE.
4. smartctl -l selftest zeigt Completed without error und die kritischen SMART-Attribute stehen auf null.
5. bonnie++: plausible Werte im Bereich der Herstellerangaben.

Zum Schluss das Kernel-Log auf Hardware-Fehler prüfen, etwa Machine-Check-Exceptions (MCE) oder I/O-Errors:

sudo dmesg --level=err,warn | grep -iE "mce|hardware error|i/o error|ata"
journalctl -k -p err --no-pager

Verifizieren: Alle fünf Punkte der Liste treffen zu, und die beiden Log-Befehle liefern keine Einträge zu mce, Hardware Error oder I/O error aus dem Testzeitraum.

Updates und Wartung

Halten Sie die smartmontools aktuell, damit die Laufwerks-Datenbank neue Modelle erkennt; Datenbank und Pakete regelmäßig aktualisieren:

# Pakete aktualisieren (Debian/Ubuntu)
sudo apt update && sudo apt upgrade -y stress-ng smartmontools

# SMART-Laufwerksdatenbank aktualisieren
sudo update-smart-drivedb

Für den Dauerbetrieb empfiehlt sich der smartd-Dienst, der SMART-Werte automatisch überwacht und per Mail warnt, sobald Attribute kritisch werden. Aktivieren Sie ihn nach Bedarf und konfigurieren Sie /etc/smartd.conf. So müssen Sie nicht manuell prüfen, sondern werden proaktiv informiert. Wie das im Detail geht, zeigt die Anleitung SMART-Monitoring mit smartd und Scrutiny. Planen Sie außerdem regelmäßige kurze SMART-Selbsttests (smartctl -t short) ein, etwa wöchentlich per Cronjob.

Backup-Hinweis: Ein bestandener Stresstest ersetzt kein Backup. Gerade bei gebrauchter Hardware oder Laufwerken mit auffälligen SMART-Werten sollten Sie eine durchdachte Backup-Strategie fahren. Wie Sie Datenträger vor dem Wiederverkauf rückstandslos leerst, zeigt unsere Anleitung zum sicheren Löschen von Festplatten.

Troubleshooting

1. System friert unter stress-ng ein oder startet neu: Überhitzung oder instabile Spannung. Temperaturen prüfen, Kühler reinigen, Wärmeleitpaste erneuern, Übertaktungen oder XMP/EXPO-Profile im BIOS deaktivieren.
2. memtester meldet FAILURE: Riegel einzeln testen und Steckplätze tauschen, um einen Slot-Defekt auszuschließen; bleibt der Fehler, ist der Riegel defekt.
3. smartctl meldet „Device does not support SMART“ oder nichts: Bei USB-Gehäusen oder RAID-Controllern den Gerätetyp angeben, z. B. sudo smartctl -d sat -a /dev/sda, -d nvme oder -d cciss,0.
4. bonnie++ verweigert den Start als root: als normaler Benutzer starten oder -u nutzen.
5. sensors zeigt keine Temperaturen: sudo sensors-detect erneut ausführen, vorgeschlagene Kernelmodule laden, Mainboard-Unterstützung durch lm-sensors prüfen.
6. Current_Pending_Sector steigt: Sofort Daten sichern; das Laufwerk stirbt.

Häufige Fragen

Wie lange sollte ein Hardware-Stresstest unter Linux laufen?

30 bis 60 Minuten Volllast für einen Funktionstest; für seltene Fehler oder thermische Probleme, etwa bei gebrauchter Server-Hardware, 8 Stunden oder länger, da sich manche Defekte erst nach längerer Wärmeentwicklung zeigen.

Was bedeutet ein Crash während des stress-ng-Tests?

Meist Überhitzung oder instabile Spannungsversorgung, nicht zwingend ein defekter Chip: Temperaturen und Stromversorgung prüfen, Übertaktungen deaktivieren, erneut testen. Reproduzierbare Datenfehler deuten auf einen echten Defekt.

Reicht stress-ng allein, um RAM-Fehler zu finden?

Nein, siehe Schritt 5: zusätzlich memtester oder Memtest86+ vom Bootmedium.

Schadet ein Stresstest meiner Hardware?

Bei funktionierender Kühlung und Standard-Einstellungen ist ein zeitlich begrenzter Test unbedenklich; die Komponenten sind für Volllast ausgelegt. Temperaturen beobachten, Notebooks am Netzteil. Für bonnie++ (echte Schreiblast) ein gültiges Backup.

Worin unterscheiden sich smartctl -t short und -t long?

-t short dauert wenige Minuten und prüft elektrische und mechanische Grundfunktionen; -t long scannt die gesamte Oberfläche in mehreren Stunden und findet Lesefehler deutlich gründlicher.

Fazit

stress-ng deckt instabile Systeme und Kühlungsprobleme auf, memtester Speicherfehler, bonnie++ misst den realen Durchsatz, smartctl liefert die SMART-Diagnose. Mit Temperatur-Monitoring per watch -n 1 sensors grenzen Sie Defekte ein, bevor sie im Produktivbetrieb schaden. Planen Sie 30 bis 60 Minuten für den Standardfall, mehrere Stunden für kritische Hardware.

Weiterführende Anleitungen und Quellen

Für die dauerhafte Überwachung Ihrer Laufwerke eignet sich SMART-Monitoring mit smartd und Scrutiny. Für die sichere Außerbetriebnahme geprüfter Datenträger finden Sie in unserer Anleitung zum sicheren Löschen von Festplatten alle Schritte. Weitere praxisnahe Tutorials sammeln wir in der Kategorie Hardware.

Quellen: Offizielle Projektdokumentation von stress-ng, smartmontools und bonnie++.