Performance Guide

Performance-Guide (B42)

← Home · Zurück: Server-Konfiguration

Alles über Performance des Project-Zomboid-B42-Servers: Memory/JVM, Storage, CPU-Optionen, Modlisten-Budget und Schnelldiagnose. Basis ist die Repo-Checkliste docs/09-performance.md (vollständig übernommen), erweitert um gelabeltes Community-Wissen aus den B42-Tuning-Guides.

Label-Legende: (Repo-Default) = das Repo setzt diesen Wert 1:1 in Template/Skript. (Community-Quelle: X) = extern belegt. (Heuristik) = begründete Empfehlung dieses Wikis / der Repo-Doku, kein offizieller Wert. The Indie Stone (TIS) veröffentlicht KEINE offiziellen Performance-Specs — jede Zahl hier ist Community- oder Repo-Wissen, nie eine TIS-Vorgabe.

0. Warum B42 anspruchsvoller ist

(aus docs/09) Build 42 (stable seit 29.07.2026 — Community-Quelle: Enzyklopädie/Release-Historie, Repo-Doku) verlagert die Last in neue Systeme: Echtzeit-Lichtpropagation, bis zu 32 Stockwerke pro Chunk (I/O-Spitzen), Tiersimulation und tiefere Crafting-Systeme laufen permanent im Hintergrund — auch wenn niemand kämpft. B41-Regeln („4-6 GB reichen") gelten nicht mehr. Community-Beobachtung: B42 braucht ≈2 GB mehr RAM als ein vergleichbarer B41-Server.

Dazu das Threading-Modell (Community-Quelle, single-source auf exakte Anteile): Die Hauptsimulation (Zombie-KI/Pfadfindung, Lighting, Chunk-Work) läuft single-threaded auf einem Kern; nur Netzwerk-I/O und Speichern können andere Threads nutzen. Mehr Kerne helfen der Simulation nicht — höhertaktige Kerne schon.

1. Memory / JVM

RAM-Tiers

Kanonik (Host-RAM-Klasse → empfohlener Heap) — dieselbe Tabelle steht in ENV-Variablen, Quickstart-Linux und Hardware-Empfehlungen (Spalten dort: „Host-RAM" und „Heap Xmx"); Quelle ist der B42-Optimierungs-Guide b42-server-optimization-checklist.md.

Klasse	Host-RAM (Gesamt)	Empfohlenes Heap Xmx	Label
Small	≤ 8 GB	6–8 GB	Community-Quelle: B42-Optimierungs-Guide
Medium	8–24 GB	10–14 GB	Community-Quelle: B42-Optimierungs-Guide
Large / Modded	24+ GB	16 GB	Community-Quelle: B42-Optimierungs-Guide

Heap-Empfehlung nach Spielerzahl

Diese Sicht ist eine Ableitung aus derselben Faustformel, nicht eine eigenständige Tier-Logik — die Zahlen müssen mit der Host-RAM-Klassen-Tabelle oben übereinstimmen (Heuristik, Repo-Doku docs/09):

Profil	Spieler/Mods	Empfohlener Heap	Label
Small	bis 8 Spieler, vanilla/leichte Mods	6–8 GB	(Heuristik, abgeleitet aus Faustformel)
Medium	8–24 Spieler, Standard-Modpacks	10–14 GB	(Heuristik, abgeleitet aus Faustformel)
Large/Modded	24+ Spieler oder schwere Mods	16 GB	(Heuristik, abgeleitet aus Faustformel)

Faustformel (Heuristik): ~6 GB Basis + 0,5 GB/Spieler, stark gemoddet +2-4 GB Mod-Puffer (Repo-Doku docs/09; Community-Beobachtung: B42 stark-gemoddet landet oft bei 14-16 GB unabhängig von der Slotzahl). Repo-Default: RAM_XMX=12G für 8 Spieler + die Repo-Modliste (1:1 aus .env.example).

Host-RAM-Rechnung (Community-Quelle): 16 GB Heap erfordern einen Host mit mindestens 24 GB RAM — dem OS müssen ~6-8 GB für Page-Cache und Chunk-Streaming bleiben, sonst swappt das System, was schlimmer ist als ein kleinerer Heap. Bei 16 GB Host-RAM also max. 12-13G Heap (aus docs/09).

Xms = Xmx und wie das Repo den Heap setzt

• -Xms gleich -Xmx setzen — kein Re-Sizing zur Laufzeit, keine Resize-Pausen, planbarer Footprint (Community-Quelle: Hosting-Guides; Konsens). Caveat (Community-Quelle, single-source): Wer allen RAM sofort reserviert, kann den OS-Page-Cache aushungern — deshalb die Host-Rechnung oben.
• Repo-Weg (systemd): Das Repo setzt NUR -Xmx: zomboid.service startet mit -Xmx${RAM_XMX} aus der .env (1:1 aus dem Service-File). Ein -Xms-Flag setzt der systemd-Pfad des Repos NICHT — wer Xms=Xmx will, ergänzt es am Start-Skript/Service (Anpassung außerhalb des unveränderten Repo-Stands; der Wertebereich stammt aus docs/09).
• Windows-Weg (aus docs/09): Flags in ProjectZomboid64.json unter vmArgs, z. B. "-Xms12g", "-Xmx12g". Siehe Setup-Windows.

Garbage Collector

Frage	Antwort	Label
Standard-Empfehlung	G1GC — kürzere GC-Pausen statt seltener langer; besser bei B42-Allokationsdruck (Crafting + Tiersimulation)	aus docs/09; Community-Quelle: Hosting-Guides (Community-disputiert, kein Konsens)
-XX:MaxGCPauseMillis	200 ist der Standardwert; 50 ist eine konservative Alternative (kürzere einzelne Pausen, weniger Durchsatz)	200=Standard: Community-Quelle JVM/Hosting-Guides; 50=Heuristik; docs/09 nennt 50
ZGC	Sehr niedrige Pausen; nur für sehr große Heaps evaluieren	Heuristik (EN-Guide: ZGC ist Default gewisser Docker-Images — unseres ist ein anderes, siehe Docker-Betrieb)
Flags setzen	Repo setzt KEINEN GC-Flag — Ergänzung wie oben über vmArgs/Start-Skript	Repo-Stand

Praxisregel (Heuristik, aus der Community): Ruckler bei Spielern → GCPauseMillis senken; CPU dauerhaft in GC → erhöhen. Immer nur eine Schraube drehen und danach messen.

OOM erkennen und beheben

(aus docs/09) make logs nach OutOfMemoryError durchsuchen → RAM_XMX in .env erhöhen → make restart. Der Healthcheck des Repos greift OutOfMemory im 5-Minuten-Fenster automatisch ab (siehe Monitoring-und-Alerts).

Verifizieren, dass Flags angekommen sind (Community-Quelle: EN-Guide, Standard-HotSpot-Tooling):

ps -ef | grep -E 'java.*zomboid|ProjectZomboid' | grep -o -- '-Xm[sx][^ ]*'
jcmd <pid> GC.heap_info          # Heap-Snapshot
# GC-Log aktivieren (Analyse nach Lastspitzen):
# -Xlog:gc:file=gc.log:time,uptime,level,tags

2. Storage / Map-Streaming

B42 streamt bis zu 32 Etagen Voxel-Daten pro Chunk — Hauptgrund für Micro-Freezes beim Betreten von Städten und bei Autofahrten (aus docs/09).

Storage-Tiers

Storage	Eignung	Praxis	Label
HDD	Ungeeignet	Spürbare Ladeblöcke	aus docs/09; Symptomlage Community-Quelle: Vendor-Beobachtungen
SATA SSD	Akzeptabel	Minimum für kleine Gruppen	aus docs/09 (Guide-Empfehlung)
NVMe	Sehr gut	Empfohlener Standard	aus docs/09 (Guide-Empfehlung)
PCIe Gen4 NVMe	Ideal	Bei mehreren gleichzeitig fahrenden Spielern	aus docs/09 (Guide-Empfehlung)

Es gibt KEINE offiziellen TIS-IOPS/MB/s-Specs — Vendor-Zahlen sind Marketing, keine B42-Anforderung (Community-Quelle: Storage-Guide-Recherche). Messen statt glauben, siehe Schnelldiagnose unten.

Weitere Punkte aus docs/09:

• NVMe für Server + Saves — kein HDD-Betrieb.
• Antivirus-Ausschluss: B42 nutzt ein neues SQLite-Format für den Map-Cache; Echtzeit-Scanner sperren die Dateien → I/O-Locks. Ausschluss für Zomboid/Saves/Multiplayer/ (betrifft v. a. Windows-Hosts).
• Fahrzeug-Tempo begrenzen (Sandbox): Vollgas durch dichte Gebiete erzwingt Echtzeit-Chunk-Loads → Rubber-Banding. Eher Chunk- als Netzwerkproblem.

Latenz-Schwellwerte messen (Heuristik — aus dem Storage-Guide)

Schwellwerte als Starthilfen, NICHT vendor-dokumentiert (alles Heuristik):

Metrik (iostat -x/vmstat)	Gesund	Degradiert	Kritisch
Device await	<1 ms	1-5 ms	>5 ms anhaltend
Device %util	<50 %	50-85 %	>85 % anhaltend
CPU iowait	<2 %	2-10 %	>10 %
Save-Burst-Dauer	<2 s	2-5 s	>5 s

iostat -x 2                                   # Device-Latenz/-Auslastung (Paket sysstat)
pidstat -d -p $(pgrep -fi zomboid) 2          # Disk-Aktivitaet des JVM-Prozesses
vmstat 2                                      # iowait (Spalte wa), Swap-Druck

Auswertungslogik (Heuristik, Storage-Guide): await + iowait gemeinsam erhöht = starker Storage-Verdacht; beide gesund → JVM/GC, Zombie-Dichte, Netzwerk prüfen. Messung immer mit Spielerbericht und Save-Zeitpunkt korrelieren; Einzelmessungen weniger wert als wiederholbare Muster.

tmpfs-Ansatz (Option außerhalb des Repo-Stands)

Das Repo hat KEIN tmpfs-Setup — alles Folgende ist ein_optionaler_ Ausbau aus dem Storage-Guide (Standard-Linux-tmpfs+rsync-Muster, keine TIS-Empfehlung; Heuristik): Zomboid/Saves/Multiplayer auf tmpfs legen, Größe ≈ aktuelle Save-Größe × 1,5, plus Boot-Seed-Service, Sync-Back-Timer (z. B. alle 5 Min) und ExecStop-rsync. Risiko-Box des Guides: RAM-Disk ist KEIN Backup; Stromverlust kostet alles seit dem letzten Sync; die Kapazitätsrechnung (Heap + Saves + 8 GB OS-Reserve + Puffer) muss aufgehen — auf einem 24-GB-Host mit 12G Heap bleibt dafür wenig Luft. Empfehlung (Heuristik): erst NVMe, tmpfs nur bei großer RAM-Reserve experimentell.

3. CPU-Last senken (server.ini)

Diese Performance-Optionen sind im Repo-Template config/templates/servertest.ini.tmpl voreingestellt (Werte 1:1 = Repo-Default; die Werte selbst stammen aus der Community — Community-Quelle: Hosting-Guides, single-source):

# Virtuelle Zombies: begrenzt teure Echtzeit-Updates
ZombieUpdateMaxHighPriority=50      # max. Zombies mit voller Update-Rate
ZombieUpdateDelta=0.5               # Sekunden zwischen Zombie-Bulk-Updates
ZombieUpdateRadiusHighPriority=10.0 # Radius volle Sim (0.0 = altes Verhalten)
ZombieUpdateRadiusLowPriority=45.0  # dahinter nur noch Low-Prio-Updates

# B42-Lighting: Echtzeit-Lichtpropagation ist ein Dauer-CPU-Verbraucher
LightingUpdateInterval=0.5

# Welt-Hygiene
HoursForWorldItemRemoval=48
RemovePlayerCorpsesOnCorpseRemoval=true
SaveWorldEveryMinutes=15
PauseEmpty=true

Begründungen (aus docs/09):

• Zombie-Update-Settings: Entfernte Zombies werden nur gebündelt und verzoegert aktualisiert — bei 8 Spielern quasi unsichtbar, bei großen Horden um Basen der Unterschied zwischen 60 und 20 TPS (Angabe aus docs/09). Hintergrund (Community-Quelle): Distanz-Zombies sind „virtuell" — weniger Dichte/Updates = weniger Arbeit für den einzelnen Simulations-Thread.
• LightingUpdateInterval=0.5: Höheres Intervall = weniger CPU, Lichtwechsel wirken minimal verzögert. WICHTIG (aus docs/09): Dieser Key ist B42-neu — nach erstem Boot im Log verifizieren, dass er greift (Keys werden zwischen Builds gelegentlich umbenannt; unbekannte Keys werden still ignoriert). Zu zirkulierenden angeblichen Lighting-Keys, die NICHT existieren: Mythen-Kasten in Server-Konfiguration.
• Welt-Hygiene: HoursForWorldItemRemoval=48 und RemovePlayerCorpsesOnCorpseRemoval=true halten Item- und Leichen-Berge klein (Datenmüll = RAM + CPU).
• SaveWorldEveryMinutes=15 = Autosave-Intervall (Repo-Default).
• PauseEmpty=true = Server pausiert ohne Spieler, verbraucht dann fast nichts (Repo-Default).

Ergänzung aus der Community (NICHT im Repo-Template, Community-Quelle: EN-Optimierungs-Guide): TrashDeleteAll=true räumt fallen gelassenen Müll aggressiv weg — für lange laufende Welten empfohlen, um Memory flach zu halten.

4. CPU-Last senken (SandboxVars)

Im Preset config/presets/sandbox/coop-balanced.lua gesetzt (Preset-Werte = Repo-Default); bei Lag hier drehen (Empfehlungen aus docs/09 = Heuristik der Repo-Doku):

Setting	Preset-Wert	Bei Lag	Wirkung
Zombies	4 (Normal)	5 (Low)	Größter einzelner CPU-Faktor. Skala INVERTIERT: 1=Insane, 4=Normal, höhere Zahl = weniger Zombies
PopulationMultiplier	1.0	0.65	Gesamt-Population (4.0=Insane ... 0=None)
RespawnHours	0	0 lassen	0 = kein Respawn = keine Respawn-Berechnung
ErosionSpeed	Default	3	Höher = mehr Berechnung
CarSpawnRate	3	2	Fahrzeuge sind teure Entities
BloodLevel	1	1 lassen	Blut-Decals akkumulieren RAM
HoursForCorpseRemoval	72	24-48	Leichen sind Datenmüll

Weitere Werte des Presets (Repo-Default, 1:1): LootRespawn=1 (aus), DayLength=3, XpMultiplier=1.5, SleepAllowed=false, PVP=false, SafetySystem=true, Safehouse=true, PlayerSafehouse=true.

Community-Einordnung (EN-Guide): PopulationMultiplier senken ist der größte CPU-Hebel überhaupt, weil weniger Zombies je in die Live-Simulation befördert werden (virtuelles Zombie-System).

Population über die Zeit steuern (Community-Quelle: pzwiki-Sandbox-Defaults). Genauer Repo-Stand des Presets: PopulationStartMultiplier = 0.8 und PopulationPeakMultiplier = 1.5 sind bereits gesetzt (Repo-Default, 1:1 aus coop-balanced.lua); PopulationPeakDay fehlt im Preset und kann bei Bedarf ergänzt werden. Die Beispielwerte 0.65/1.0/28 stammen aus dem EN-Guide (Community-Quelle bzw. Heuristik des Leitfadens, keine TIS-Vorgabe):

PopulationMultiplier = 0.65,      -- EN-Guide-Beispiel; Repo-Default: 1.0
PopulationStartMultiplier = 1.0,  -- EN-Guide-Beispiel; Repo-Default: 0.8
PopulationPeakMultiplier = 1.5,   -- EN-Guide-Beispiel; zugleich Repo-Default
PopulationPeakDay = 28,           -- EN-Guide-Beispiel; nicht im Preset

Warnung: Wer das Low-Lag-Beispiel übernimmt, überschreibt den Repo-Default PopulationStartMultiplier = 0.8 („sanfter Einstieg") still mit 1.0 — bewusst entscheiden, nicht blind kopieren; nicht gesetzte Keys behalten ihre Vorgabewerte.

Cache-Neuaufbau nach Populations-Änderung (Community-Quelle, single-source): Der Server cached die Zombie-Karte in zpop_*.bin im World-Save-Verzeichnis. Nach Änderungen an Population-/Update-Optionen:

# im World-Save-Verzeichnis (z. B. /opt/pzserver/Zomboid/Saves/Multiplayer/<server>/)
rm zpop_*.bin   # sicher: Spieler-/Item-/Safehouse-Daten liegen woanders

…und Server neu starten, damit die Populations-Karte neu aufgebaut wird.

5. Große Modlisten hosten

(aus docs/09, erweitert)

• Budget: Jede Mod kostet RAM + Startup-Zeit + Per-Tick-CPU. Grobe Obergrenze ~30 Mods auf moderater Hardware (Heuristik aus docs/09).
• RAM-Aufschlag: stark gemoddet +2-4 GB über Baseline (docs/09) — damit landet man im Large-Tier 24+/16 GB der Tabelle oben (Community-Quelle).
• Eine Mod nach dem anderen aktivieren, dazwischen make status — nie 10 gleichzeitig, sonst ist der Verursacher nicht isolierbar (docs/09; Modliste verwalten: Mods-Referenz).
• Log-Spam = Lag-Indikator: make logs nach Warnungs-Dauerfeuer durchsuchen. Praxisfall des Repos: Neat Building mit Invalid SpriteConfig object!-Spam (Aug 2026) → im Repo deaktiviert (Repo-Erfahrung aus docs/09).
• Doppel-Funktionen vermeiden: nur EIN Waffen-Overhaul, EIN Inventar-System, EINE Karten-Erweiterung pro Region (docs/09).
• Karten-Mods sind die teuersten: jede zusätzliche Karte = mehr Chunk-Daten + längere Ladezeiten + höherer Save-Ordner (docs/09).
• Load-Order: Eintragsreihenfolge in Mods=/WorkshopItems= ist die Lade-Reihenfolge — Frameworks zuerst (Community-Quelle; das Repo erzeugt die Reihenfolge automatisch aus mods.yaml-Kategorien, siehe Modding-Workflow). Die Map=-Zeile: semikolongetrennte interne Ordnernamen, frühere Maps gewinnen, Muldraugh, KY immer zuletzt (Community-Quelle: Repo-Changelog 0.3.0 + docs). Eine sehr lange Map=-Zeile ist auch ein Ladezeiten-Treiber (Heuristik aus dem EN-Guide: jede Karte addiert Chunk-Daten).

6. Betrieb / Wartung

(aus docs/09)

• Geplante Neustarts alle 12-24h gegen Memory-Fragmentierung — im Repo automatisch abgedeckt: Backup-Timer 04:00 täglich (systemd-Timer, Repo-Default) + Update-Timer Di 03:00 (Werte aus .env.example: UPDATE_DAY=Tue, UPDATE_TIME=03:00; das systemd-Timer-File templated sie nur — siehe Wartung-und-Automatik).
• PauseEmpty=true (Repo-Default im Template) — leerer Server verbraucht fast nichts.
• Monitoring: make status (Prozess/Port/Log) + make logs — Details Monitoring-und-Alerts.
• Baseline messen: nach frischem Restart TPS/Last notieren, nach 3 Tagen Betrieb vergleichen — driftet es, hilft der Restart-Rhythmus oder ein Mod-Audit (Heuristik aus docs/09).
• Backups außerhalb der Spielzeiten platzieren (Heuristik: der 04:00-Default des Repo-Timers passt zu abendlicher Coop-Zeit; wer nachts spielt, verschiebt — siehe Backup-und-Restore).

7. Hardware-Prioritäten

Wenn Software nicht mehr reicht (aus docs/09, Reihenfolge dort 1-4):

1. Single-Core-Takt — PZ skaliert kaum über Kerne; die Simulation ist single-threaded (Community-Quelle). docs/09 nennt als Beispiele Ryzen 7950X/9950X; die Community zielt auf ~4,5 GHz Boost minimum (Community-Quelle, single-source).
2. NVMe Gen4 — Chunk-Streaming (Abschnitt 2).
3. RAM — stabil und ausreichend, nicht maximal: der Heap-Tier-Rechnung aus Abschnitt 1 folgen, OS-Puffer einplanen.
4. Upload — 10+ Mbit/s stabil für 8 Spieler (aus docs/09).

NICHT erwarten: Der Server nutzt N Kerne für die Simulation — er tut es nicht, egal welche Flags (Community-Quelle; wer das behauptet, verbreitet Fehlinformation).

8. Schnell-Diagnose bei Symptomen

Erweitert aus docs/09 um konkrete Messbefehle:

Symptom	Messung	Typische Ursache	Siehe auch
Rubber-Banding beim Fahren	iostat -x 2 (await/%util), Spieler-Tempo	Chunk-Loading (Storage/CPU)	Abschnitt 2; Ports-und-Netzwerk für Netzweg
Micro-Freezes in Städten	iostat -x 2, vmstat 2 (wa)	32-Etagen-I/O	Abschnitt 2
„Black Box"-Tiles	CPU-Auslastung pidstat -t / htop (pro Kern)	Licht-/CPU-Last im Sim-Thread	Abschnitt 3 (LightingUpdateInterval, mit Verifikationshinweis)
Zombie-Pop-in	SandboxVars ansehen	Population zu hoch	Abschnitt 4
Disconnects nach Stunden	make logs nach OutOfMemoryError; jcmd <pid> GC.heap_info	Memory-Fragmentierung/OOM	Abschnitt 1
Ruckler in regelmäßigen Abständen	Save-Zeitpunkte ins Log korrelieren	Autosave-Bursts (alle 15 Min, Repo-Default) auf langsamem Storage	Abschnitte 2 + 6
Hohe GC-Pausen	GC-Log (-Xlog:gc), jcmd <pid> GC.heap_info	Heap zu klein / GC-Tuning	Abschnitt 1
Dauerhafter IO-Wait	iostat -x 5: %util/await >70 % unter normaler Last (Community-Quelle, single-source-Schwelle)	Save-Device gesättigt (Backups/andere Jobs concurrent?)	Abschnitte 2 + 6
Lange Join-Zeiten (bestehender Server)	Mod-Anzahl vs. Tier-Tabelle	Mod-Budget/RAM	Abschnitte 1 + 5

(Join-Verzögerung beim allerersten Boot einer frischen Welt ist normal — Weltgenerierung; siehe Troubleshooting.)

Zu erfundenen Performance-Optionen, die in Foren kursieren und NICHT existieren (unbekannte ini-Keys werden still ignoriert): Mythen-Kasten in Server-Konfiguration. Hier bewusst nicht wiederholt.

Vertieft in Repo: docs/09-performance.md (Checklisten-Original), .env.example (RAM_XMX), config/templates/servertest.ini.tmpl, config/presets/sandbox/coop-balanced.lua.

---

Weiter: Troubleshooting · Monitoring-und-Alerts · Wartung-und-Automatik