← Blog

DayZ Server Performance: welche technischen Faktoren wirklich zählen

Par Benjamin D. · PDG

· Mis à jour le 2. September 2026 · Lecture 7 min

Inhaltsverzeichnis

Die DayZ Server Performance hängt an deutlich weniger Stellschrauben, als viele Admins vermuten – aber diese Stellschrauben sind hart. Die Enfusion-Engine arbeitet stark auf einem einzelnen Haupt-Thread, reagiert empfindlich auf Entity-Zahlen und quittiert überladene Mod-Listen mit Rubberbanding. Dieser Artikel zeigt, welche Rolle CPU-Takt, Arbeitsspeicher, Central Economy und Mod-Auswahl wirklich spielen.



Warum die DayZ Server Performance an der Single-Core-Leistung hängt

DayZ läuft auf der Enfusion-Engine. Ein Großteil der Simulation – Spielerbewegung, Infizierten-KI, Item-Lifetime, Netzwerk-Replikation – wird auf einem dominanten Haupt-Thread abgearbeitet. Nebenläufige Aufgaben wie Replikation lassen sich zwar auslagern (multithreadedReplication), aber die Kernschleife bleibt seriell. Praktische Konsequenz: Ein Prozessor mit hohem Takt und starker Single-Core-Leistung liefert spürbar stabilere Server-FPS als eine CPU mit vielen, aber langsamen Kernen.

Deshalb ist die Ryzen-Generation mit hoher Taktfrequenz bei Fly-Serv die passende Basis für Survival-Titel dieser Bauart. Wer die Infrastruktur nicht selbst betreiben will, findet die passende Konfiguration direkt auf der Seite DayZ Server mieten.

Was „Server-FPS" in DayZ bedeutet

Anders als bei Source-Titeln gibt es keine frei einstellbare Tickrate. DayZ arbeitet mit Server-Frames: Je mehr Frames pro Sekunde der Server schafft, desto häufiger werden Positionen, Treffer und Item-Interaktionen verarbeitet. Fällt der Wert unter etwa 15–20 FPS, spüren Spieler das sofort:

  • verzögerte Türen, Zelte und Container-Interaktionen
  • Infizierte, die „nachziehen" oder durch Wände greifen
  • Desync beim Loot-Transfer, Items verschwinden kurzzeitig
  • Rubberbanding beim Sprinten oder im Fahrzeug

Startparameter, die direkt auf die CPU wirken

./DayZServer \
  -config=serverDZ.cfg \
  -port=2302 \
  -profiles=profiles \
  -BEpath=battleye \
  -cpuCount=4 \
  -limitFPS=200 \
  -dologs -adminlog -netlog -freezecheck

-cpuCount begrenzt die Anzahl der genutzten logischen Kerne. Mehr als 4 bringt in der Praxis selten etwas, weil die Hauptschleife nicht skaliert. -limitFPS deckelt die Server-Frames; ein Deckel bei 200 verhindert, dass ein leerer Server unnötig Rechenzeit zieht. -freezecheck beendet den Prozess bei einem Deadlock, was in Kombination mit einem Auto-Restart im Panel Ausfallzeiten verkürzt. Die vollständige Parameterliste steht in der offiziellen Bohemia-Dokumentation.



RAM-Bedarf nach Spielerzahl und Modumfang

Arbeitsspeicher ist in DayZ kein „nice to have". Der Server hält Terrain, Central-Economy-Datenbank, alle persistenten Objekte (Zelte, Fässer, Basen, Fahrzeuge) und sämtliche Mod-Assets im RAM. Läuft der Speicher voll, beginnt das System zu swappen – und dann brechen die Server-Frames schlagartig ein.

Richtwerte für die Dimensionierung

SetupSlotsRAM (Richtwert)Anmerkung
Vanilla Chernarus10–204 GBStandard-Loot, wenig Persistenz
Vanilla Chernarus / Livonia40–606–8 GBviele Zelte und Fahrzeuge erhöhen den Bedarf
Leicht modded (QoL, Trader)40–608–12 GBabhängig von Basenbau-Objekten
Schwer modded (Expansion, Custom Map)60–10012–16 GB+Namalsk, Deer Isle, Banov: Terrain-Assets im Speicher

Diese Zahlen sind Erfahrungswerte aus der Administration, keine harte Formel. Wichtiger als das absolute Maximum ist der Verlauf: Wenn der Speicherverbrauch zwischen zwei Restarts kontinuierlich steigt und nie zurückgeht, hast du entweder einen Mod mit Leak oder eine Persistenz, die nie aufgeräumt wird.

Speicherverbrauch beobachten

# Prozessspeicher live beobachten
htop -p $(pgrep -f DayZServer)

# Snapshot in eine Datei schreiben (für Verlaufsanalyse)
ps -o rss=,vsz= -p $(pgrep -f DayZServer) >> /var/log/dayz_mem.log

Storage: warum NVMe hier zählt

Die Central Economy schreibt Persistenzdaten regelmäßig auf die Platte. Bei einer großen Basenbau-Community mit tausenden platzierten Objekten wird jeder Storage-Flush zu einer I/O-Spitze. Auf klassischen Festplatten führt das zu kurzen Freezes für alle Spieler; auf NVMe-SSDs ist derselbe Vorgang unauffällig. Gleiches gilt für den Serverstart: Das Einlesen von Mod-PBOs ist reine Lese-I/O, und die Startzeit unterscheidet sich zwischen den Speichertypen deutlich.



Mods, Entity-Last und Central Economy

Mods sind der häufigste Grund für schlechte Server-Frames. Nicht die Anzahl allein ist entscheidend, sondern was ein Mod pro Frame tut: Skripte, die auf jedem Tick über alle Spieler oder alle Objekte iterieren, sind der klassische Performance-Killer.

Client-Mods und Server-Mods trennen

-mod=@CF;@Dabs Framework;@DayZ-Expansion-Core;@DayZ-Expansion-Chat
-servermod=@AdminTools;@ServerLogger

Alles, was nur serverseitig arbeitet (Admin-Werkzeuge, Logging, Loot-Verwaltung), gehört hinter -servermod. So müssen Spieler diese PBOs nicht laden, die Verbindungszeit sinkt und die Signaturprüfung bleibt schlank. Die Reihenfolge in -mod ist nicht beliebig: Frameworks wie CF gehören immer vor die Module, die auf ihnen aufbauen.

Die zentralen Regler in globals.xml

Die Datei mpmissions/<deine Mission>/db/globals.xml steuert, wie viele Entities überhaupt gleichzeitig existieren dürfen. Hier lässt sich mit wenigen Werten viel Last einsparen:

<var name="ZombieMaxCount"      type="0" value="800"/>
<var name="AnimalMaxCount"      type="0" value="150"/>
<var name="IdleModeStartup"     type="0" value="1"/>
<var name="IdleModeCountdown"   type="0" value="60"/>
<var name="CleanupLifetimeRuined" type="0" value="330"/>
<var name="CleanupLifetimeDeadPlayer" type="0" value="3600"/>
<var name="TimeLogin"           type="0" value="15"/>
  • ZombieMaxCount: jeder Infizierte ist eine KI-Instanz mit Pathfinding. Von 1000 auf 800 zu gehen, ist der schnellste Hebel gegen CPU-Last – zulasten der Spielhärte.
  • IdleModeStartup / IdleModeCountdown: der Server schaltet in einen Ruhemodus, wenn niemand online ist. Spart Rechenzeit und verhindert, dass die Economy nachts sinnlos durchläuft.
  • CleanupLifetime*: zerstörte Objekte und Leichen, die zu lange liegen bleiben, summieren sich zu tausenden Entities.

types.xml und events.xml im Blick behalten

Wer die nominal-Werte in der types.xml pauschal verdreifacht, weil „mehr Loot mehr Spaß" bedeutet, erzeugt zehntausende zusätzliche Objekte auf der Karte. Jedes davon hat eine Lifetime, wird vom Cleanup verwaltet und belegt Speicher. Dasselbe gilt für events.xml: Zu viele gleichzeitig aktive Fahrzeug- und Heli-Crash-Events erhöhen die Entity-Zahl dauerhaft.

Faustregel aus der Praxis: Erhöhe niemals Loot-Nominals und Zombie-Count in derselben Änderung. Sonst weißt du nach dem Restart nicht, welche Anpassung die Server-Frames gedrückt hat.

Netzwerkparameter in serverDZ.cfg

Die Replikations-Reichweiten bestimmen, wie viele Objekte pro Spieler synchronisiert werden. Auf einer dicht bebauten Karte mit großen Basen lohnt sich Feinjustierung:

defaultVisibility           = 1375;
defaultObjectViewDistance   = 1375;
networkRangeClose           = 20;
networkRangeNear            = 150;
networkRangeFar             = 1000;
networkRangeDistantEffect   = 4000;
networkObjectBatchCompute   = 1000;
networkObjectBatchSendCreate = 10;
networkObjectBatchSendDelete = 10;
networkObjectBatchLogSlow   = 5;
simulatedPlayersBatch       = 20;
multithreadedReplication    = 1;

networkObjectBatchLogSlow schreibt eine Warnung ins .RPT-Log, sobald ein Replikations-Batch länger als der angegebene Wert in Millisekunden braucht. Tauchen diese Zeilen gehäuft auf, ist die Objektdichte auf der Karte das Problem, nicht die Leitung.



Stabilität im Betrieb: Monitoring, Restarts und Wartung

Eine gute Ausgangskonfiguration hält nicht ewig. DayZ-Server sammeln über Wochen Persistenzdaten an, und genau dort entsteht der schleichende Leistungsverlust.

Restart-Zyklen sinnvoll setzen

Ein Neustart alle 3 bis 4 Stunden ist auf den meisten Communities Standard. Er gibt Speicher frei, setzt die Economy-Queues zurück und respawnt Fahrzeuge sauber. Über die Panel-Automatisierung im Pterodactyl-Panel lassen sich diese Restarts planen, inklusive Ankündigung über BEC oder ein Server-Mod. Wichtig: Restart-Zeitpunkte nicht auf volle Stunden legen, wenn zeitgleich die Sicherung läuft – doppelte I/O-Last beim Herunterfahren erzeugt genau die Freezes, die du vermeiden willst.

Logs, die du regelmäßig prüfen solltest

  • .RPT – Skriptfehler, fehlende Klassen, langsame Netzwerk-Batches. Wiederkehrende Fehlermeldungen eines Mods sind fast immer auch ein Performance-Problem.
  • .ADM – Spieleraktionen, Verbindungen, Kills. Nützlich für Moderation und zum Erkennen von Spitzenlast-Zeiten.
  • crash-Dumps – wiederholte Abstürze an derselben Stelle deuten auf einen inkompatiblen Mod nach einem Spiel-Update hin.
# Skriptfehler der letzten Session herausfiltern
grep -i -E "error|cannot|missing" profiles/*.RPT | tail -n 50

# Langsame Netzwerk-Batches zählen
grep -c "NetworkObjectBatch" profiles/*.RPT

Updates kontrolliert einspielen

Nach jedem DayZ-Patch müssen Serverdateien und Mods zusammenpassen. Ein Update ohne Validierung der Dateien führt regelmäßig zu Startschleifen:

steamcmd +force_install_dir /home/dayz \
  +login anonymous \
  +app_update 223350 validate \
  +quit

Vor jedem Update gehört eine Sicherung der mpmissions und der Persistenzdatenbank dazu. Automatische Sicherungen im Panel decken den Regelfall ab; vor größeren Eingriffen lohnt zusätzlich ein manueller Snapshot, den du gezielt zurückspielen kannst.

Absicherung des laufenden Betriebs

Volumetrische Angriffe fängt der Anti-DDoS-Schutz auf Infrastrukturebene ab. Was du selbst absichern musst: ein starkes RCON-Passwort in der BEServer_x64.cfg, getrennte Panel-Zugänge für Moderatoren über Subuser statt eines geteilten Hauptkontos, sowie verifySignatures = 2; und forceSameBuild = 1; in der serverDZ.cfg. Letzteres verhindert, dass Clients mit manipulierten oder veralteten PBOs verbinden – ein Punkt, der Moderationsaufwand und Skriptlast gleichermaßen reduziert.

Ähnliche Prinzipien gelten für andere Survival-Titel mit persistenter Welt; einen Überblick über die unterstützten Spiele gibt Alle unsere Gameserver, weitere technische Anleitungen findest du im Fly-Serv Blog.



Fazit

Die DayZ Server Performance steht und fällt mit drei Dingen: einer CPU mit starker Single-Core-Leistung, genug Arbeitsspeicher für Persistenz und Mod-Assets, und einer Konfiguration, die die Entity-Zahl im Griff behält. Wer globals.xml, types.xml und die Mod-Liste diszipliniert pflegt, hält die Server-Frames stabil – auch auf einer vollen Karte mit 60 Spielern und ausgebauten Basen.



FAQ

Wie viele CPU-Kerne braucht ein DayZ-Server wirklich?

Vier logische Kerne reichen in fast allen Fällen aus, weil die Enfusion-Hauptschleife nicht über viele Kerne skaliert. Setze -cpuCount=4 und achte stattdessen auf hohen Takt. Mehr Kerne helfen erst, wenn auf derselben Maschine zusätzliche Dienste wie Datenbank, Discord-Bot oder ein zweiter Serverprozess laufen.

Warum ruckelt mein Server erst nach mehreren Wochen Laufzeit?

Das ist typischerweise angesammelte Persistenz: tausende Zelte, Fässer, zerstörte Fahrzeuge und Leichen, die nie aufgeräumt wurden. Prüfe die CleanupLifetime-Werte in der globals.xml, senke die Lifetime für ruinierte Objekte und kontrolliere, ob der Storage-Ordner ungewöhnlich stark gewachsen ist. Ein Persistenz-Wipe löst das Problem, sollte aber angekündigt werden.

Welche Mods belasten die Serverleistung am stärksten?

Mods mit dauerhaft laufenden Skript-Schleifen: großflächige KI-Systeme, komplexe Trader-Netze, Raid-Mechaniken mit vielen dynamischen Objekten und Karten-Erweiterungen mit hoher Objektdichte. Aktiviere neue Mods immer einzeln, beobachte die .RPT-Logs auf Skriptfehler und vergleiche die Server-Frames vor und nach der Aktivierung, statt mehrere Änderungen gleichzeitig auszurollen.