disk ioperformancechunk savinglagstoragepaperspigotserver optimization

Minecraft Server Disk-I/O optimieren: Storage-Engpässe als Lag-Ursache beseitigen

Veröffentlicht am 16. August 2026

# Minecraft Server Disk-I/O optimieren: Storage-Engpässe als Lag-Ursache beseitigen

Wenn Minecraft-Server-Admins auf Lag-Suche gehen, prüfen sie meistens CPU-Auslastung, RAM und TPS. Dabei wird ein häufig übersehener Übeltäter ignoriert, der die Server-Performance still und leise ruinieren kann: Disk-I/O. Wenn dein Server ständig Chunks, Logs und Datenbankdateien schneller liest und schreibt, als dein Speicher verarbeiten kann, bekommst du Lag-Spikes und Ruckler — egal wie leistungsstark deine CPU ist.

Dieser Guide erklärt, warum Disk-I/O auf Minecraft-Servern Lag verursacht, und zeigt dir konkrete Konfigurationsänderungen, mit denen du das Problem behebst.

---

Warum Disk-I/O bei Minecraft-Servern wichtig ist

Minecraft-Server führen ständig Festplattenoperationen durch:

Chunk-Loading — Region-Dateien werden von der Festplatte gelesen, wenn Spieler die Welt erkunden
Chunk-Saving — Veränderte Chunks werden regelmäßig zurück auf die Festplatte geschrieben
Plugin-Daten — SQLite-, YAML- und JSON-Dateien werden laufend gelesen und beschrieben
Log-Schreiben — Konsolenausgabe wird in logs/latest.log gespeichert
Autosave — Der Server speichert in regelmäßigen Abständen alle Chunks

Auf einem belebten Server mit 50+ Spielern können diese Operationen eine langsame HDD oder sogar eine günstige SSD überlasten. Der Server-Thread wartet auf den Abschluss der Festplattenoperationen, und dein TPS bricht ein.

Das typische Symptom: Lag-Spikes, die regelmäßig auftreten (alle paar Minuten) und oft mit dem Autosave-Zyklus der Welt zusammenfallen.

---

Schritt 1: Die richtige Speicherhardware wählen

Wenn du noch auf rotierenden HDDs arbeitest, wird kein Config-Tuning den I/O-Lag vollständig beheben. Das wirkungsvollste Upgrade ist der Wechsel zu einer NVMe-SSD.

| Speichertyp | Random-Read-IOPS | Typische Latenz |

|---|---|---|

| HDD | ~100 | 5–10 ms |

| SATA-SSD | ~80.000 | 0,1 ms |

| NVMe-SSD | ~500.000+ | 0,02 ms |

Die meisten Minecraft-Hosting-Anbieter setzen heute auf NVMe-Speicher — prüfe das aber immer mit deinem Hoster. Bei Self-Hosting lohnt sich die Investition in eine NVMe-SSD für deine Weltdaten auf jeden Fall.

---

Schritt 2: Chunk-Saving in Paper und Spigot anpassen

Die wirksamsten Konfigurationsänderungen für Disk-I/O betreffen das Wie und Wann des Chunk-Savings.

`bukkit.yml` — Autosave-Intervall

ticks-per:

autosave: 6000

Der Standardwert liegt bei 6000 Ticks (5 Minuten). Erhöhe ihn auf 12000 (10 Minuten), um zu reduzieren, wie oft der Server alle Chunks auf die Festplatte schreibt. Das ist für die meisten Server sicher — im schlimmsten Absturzfall verlierst du maximal 10 statt 5 Minuten Fortschritt, was ein akzeptabler Kompromiss für deutlich flüssigere Performance ist.

Setze den Wert nicht zu hoch (z. B. 36000+), ohne eine robuste Crash-Recovery-Backup-Strategie zu haben.

`paper-world.yml` — Asynchrones Chunk-Saving

Paper erledigt Chunk-I/O standardmäßig asynchron — das ist einer der größten Vorteile gegenüber vanillem Spigot. Stelle sicher, dass du Paper (oder einen Paper-Fork wie Purpur oder Pufferfish) verwendest, um davon zu profitieren.

In aktuellen Paper-Builds kannst du folgendes prüfen:

chunk-loading-basic:

autoconfig-send-distance: true

Paper nutzt außerdem das Anvil-Region-Format mit verbesserter asynchroner I/O-Pipeline. Das muss nicht manuell konfiguriert werden — es funktioniert direkt out-of-the-box.

---

Schritt 3: Unnötige Chunk-Aktivität reduzieren

Weniger Chunk-Operationen = weniger Disk-I/O. Diese Einstellungen helfen:

`server.properties`

view-distance=8
simulation-distance=4

Wenn jeder Spieler mit view-distance=10 Hunderte von Chunks geladen hält, werden all diese Chunks gelesen und geschrieben. Reduziere view-distance auf 8 und simulation-distance auf 4 — das senkt den Chunk-I/O um 30–50 %, ohne das Spielerlebnis erheblich zu beeinträchtigen.

---

Schritt 4: Linear-Region-Dateiformat verwenden (Fortgeschritten)

Paper 1.19+ unterstützt das Linear-Region-Dateiformat, eine Alternative zum Standard-Anvil-Format (.mca). Linear-Dateien sind deutlich kleiner und schneller zu schreiben:

~50 % kleinere Dateigrößen (durch bessere Komprimierung)
Schnellere sequentielle Schreibvorgänge
Weniger IOPS unter hoher Last

Aktivierung in paper-world.yml:

world-settings: default: linear-flush-frequency: 1

format: linear

> ⚠️ Warnung: Das Linear-Format erfordert eine Weltkonvertierung und ist nicht direkt mit dem Vanilla-Minecraft-Client kompatibel. Erstelle immer ein Backup deiner Welt, bevor du wechselst. Diese Option ist am besten zuerst auf einem Staging-Server zu testen.

---

Schritt 5: Plugin-Datenspeicherung optimieren

Plugins sind eine häufig übersehene Quelle von Disk-I/O. Viele Plugins schreiben YAML- oder JSON-Dateien synchron im Main-Thread — was bei jedem Speichern von Spielerdaten zu Lag-Spikes führt.

Überprüfe deine Plugins:

Plugins, die bei jedem Login/Logout Spielerdaten speichern, sind häufige Verursacher
Plugins, die pro Spieler eigene YAML-Dateien verwenden, sollten durch Varianten mit MySQL/MariaDB-Unterstützung ersetzt werden
Prüfe, ob dein Economy-Plugin (z. B. EssentialsX) asynchrones Speichern unterstützt

Bei EssentialsX kannst du das Speicherintervall anpassen:

save-data-interval: 120

Das setzt das Autosave-Intervall auf 120 Sekunden und reduziert die Schreibhäufigkeit.

Für Permission-Plugins reduziert LuckPerms mit MariaDB-Backend den Flat-File-I/O erheblich im Vergleich zur YAML-Speicherung.

---

Schritt 6: Log-Datei-Output verwalten

Auf sehr aktiven Servern kann die Log-Ausgabe erheblichen I/O erzeugen. Reduziere die Log-Ausführlichkeit, wo möglich:

Setze den Logging-Level auf INFO (kein DEBUG in Produktion)
Konfiguriere dein Start-Skript so, dass Logs regelmäßig archiviert werden
Vermeide doppelte Logging-Pipelines, die dieselbe Ausgabe in mehrere Dateien gleichzeitig schreiben

In deinem Start-Skript:

java -Xms8G -Xmx8G ... -jar paper.jar --nogui 2>&1 | tee logs/latest.log

---

Disk-I/O auf deinem Server überwachen

Um zu bestätigen, dass Disk-I/O tatsächlich dein Engpass ist, nutze diese Linux-Werkzeuge:

# Echtzeit-Disk-I/O-Statistiken iostat -x 2 # I/O pro Prozess iotop -o # Disk-Queue-Tiefe prüfen (hohe Werte = saturierte Festplatte)

sar -d 1 5

Achte auf:

await-Werte über 5 ms (HDD) oder 1 ms (SSD) unter Last
Hohe %util-Werte (nahe 100 %) während des Autosave-Fensters
Den Minecraft-Java-Prozess in iotop mit hohem Schreib-MB/s

Wenn du PulseNode zur Serverüberwachung einsetzt, kannst du Performance-Metriken über Zeit verfolgen und Lag-Spikes mit Autosave-Intervallen korrelieren — so erkennst du viel schneller, ob Disk-I/O die eigentliche Ursache ist.

---

Schnell-Checkliste

[ ] NVMe-SSD-Speicher verwenden (keine HDD)
[ ] autosave: 12000 in bukkit.yml setzen
[ ] view-distance auf 8 und simulation-distance auf 4 reduzieren
[ ] Auf Paper wechseln für asynchrones Chunk-I/O
[ ] Plugin-Daten wo möglich auf MySQL/MariaDB umstellen
[ ] Linear-Region-Format für Fortgeschrittene evaluieren
[ ] Mit iostat oder iotop Verbesserungen verifizieren

---

Fazit

Disk-I/O ist das Letzte, was die meisten Admins prüfen — aber oft das Erste, was regelmäßige Lag-Spikes verursacht. Durch das Anpassen deiner Autosave-Intervalle, die Reduzierung von Chunk-Aktivität, den Wechsel zu asynchroner Plugin-Speicherung und die Überprüfung deiner Hardware kannst du eine ganze Klasse von Performance-Problemen eliminieren, die kein RAM- oder CPU-Upgrade beheben würde.

Wenn du kontinuierliche Transparenz darüber möchtest, wann und warum dein Server laggt — einschließlich festplattenbedingter Spikes — bietet [PulseNode](https://pulsenode.tech) Echtzeit-Monitoring und KI-gestützte Diagnosen, damit du die Ursache schnell findest, ohne jedes Mal manuell durch Logs zu wühlen.