
Minecraft Plugin-Server optimieren 2026 – Paper & Spigot Tuning
Minecraft Plugin-Server optimieren 2026: Paper & Spigot Tuning mit Aikar-Flags, Spark-Profiling, Chunk-Pregen und konkreten Werten für stabile 20 TPS.
Counter-Strike 2 hat die Art und Weise, wie Server mit Spieler-Inputs umgehen, grundlegend verändert. Valve hat mit dem Subtick-System einen Paradigmenwechsel eingeführt: Inputs werden nicht mehr nur zum nächsten Tick verarbeitet, sondern mit Zeitstempeln versehen und zwischen den Ticks ausgewertet. Das bedeutet aber nicht, dass Tickrate, Rates und Hardware-Optimierung obsolet geworden sind – im Gegenteil. Ein schlecht konfigurierter Server fällt 2026 stärker auf als zu CS:GO-Zeiten, weil Spieler bei 128 Tick und subtick-basiertem Netcode sofort spüren, wenn Hit-Registrierung, Interpolation oder Peeker's Advantage nicht sauber laufen.
In diesem Guide zeigen wir dir, wie du einen CS2 Dedicated Server unter Linux (Debian 12 / Ubuntu 24.04) von Grund auf performant aufsetzt. Wir behandeln Tickrate, Launch-Parameter, die optimale server.cfg, Kernel-Sysctl-Tuning, CPU-Governor, Docker-Setups, Monitoring und einen ehrlichen Preisvergleich zwischen Gameserver-Hosting und eigenem Root-Server.
Alle Befehle und Werte sind praxiserprobt und auf dem aktuellen CS2-Build (Stand Q1 2026) getestet. Wer bereits einen Server betreibt, kann direkt bei den Config- und Tuning-Abschnitten einsteigen.
CS2 unterstützt offiziell 128 Tick auf Community-Servern, sofern die Hardware mitspielt. Der Standard liegt bei 64 Tick. Valve betreibt seine offiziellen Premier-Server weiterhin mit 64 Tick, kompensiert das aber durch das Subtick-System. Für Community-Server, ESL-ähnliche Ligen, Faceit-Style-Portale und ambitionierte Publics ist 128 Tick dennoch die bessere Wahl – vorausgesetzt, die CPU stemmt die doppelte Tick-Frequenz.
Der Startparameter lautet schlicht:
./game/cs2.sh -dedicated -console -usercon +game_type 0 +game_mode 1 +map de_dust2 \
-tickrate 128 -maxplayers_override 12 +sv_setsteamaccount DEIN_STEAM_TOKEN +exec server.cfg
Wichtig: Die Tickrate muss beim Start gesetzt werden. Ein nachträgliches sv_tickrate per RCON existiert nicht. Bei 128 Tick verdoppelt sich die CPU-Last pro Spieler-Input, weshalb du pro CS2-Instanz mindestens 1,5 bis 2 dedizierte CPU-Kerne mit hoher Single-Core-Leistung einplanen solltest.
Faustregel für 2026: 10 Slots bei 128 Tick = 2 Kerne. 20 Slots (Casual) = 3–4 Kerne. Bei mehr als 24 Slots solltest du auf 64 Tick zurückgehen oder horizontal skalieren.
CS2 ist single-core-hungrig. Eine CPU mit 16 langsamen Kernen schlägt eine mit 8 schnellen Kernen nicht. Empfehlenswert sind Prozessoren mit hohem Boost-Takt und großem L3-Cache:
| CPU | Kerne | Boost | CS2-Instanzen (128 Tick, 10 Slots) |
|---|---|---|---|
| AMD Ryzen 9 7950X | 16C/32T | 5,7 GHz | 6–8 |
| Intel i9-13900K | 24C/32T | 5,8 GHz | 6–8 |
| AMD Ryzen 7 7700 | 8C/16T | 5,3 GHz | 3–4 |
| Intel Xeon E-2388G | 8C/16T | 5,1 GHz | 3–4 |
| AMD EPYC 7443P | 24C/48T | 4,0 GHz | 4–5 (Taktlimit) |
Beim RAM gilt: 2 GB pro CS2-Instanz plus 2 GB für das Betriebssystem. Ein Server mit vier Instanzen braucht also mindestens 10 GB, realistisch 16 GB. CS2 alloziert beim Map-Load kurzzeitig mehr Speicher, was bei zu knappem RAM zu OOM-Kills führt.
Storage: Eine NVMe-SSD ist Pflicht. Maps wie de_ancient oder de_nuke laden aus dem Workshop-Cache teils über 500 MB. Auf SATA-SSD dauert das Map-Loading 15–25 Sekunden, auf NVMe unter 5 Sekunden. Bei mehreren Instanzen solltest du die Workshop-Dateien über einen gemeinsamen Cache teilen (-noworkshop mit vorab synchronisiertem steamapps/workshop-Verzeichnis).
Ein frisch installiertes Debian oder Ubuntu ist für Gaming-Traffic nicht optimiert. Diese Sysctl-Werte gehören in /etc/sysctl.d/99-cs2.conf:
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
net.core.rmem_default = 262144
net.core.wmem_default = 262144
net.core.netdev_max_backlog = 30000
net.core.somaxconn = 4096
net.ipv4.udp_mem = 65536 131072 262144
net.ipv4.tcp_congestion_control = bbr
net.ipv4.tcp_fastopen = 3
net.ipv4.tcp_low_latency = 1
vm.swappiness = 1
vm.dirty_ratio = 10
vm.dirty_background_ratio = 5
Danach sysctl --system ausführen. Der wichtigste Wert ist net.core.rmem_max – ohne diesen Wert kann der UDP-Receive-Buffer bei 128 Tick überlaufen, was sich in Form von Rubberbanding und Packet-Loss äußert.
Der CPU-Governor muss auf performance stehen. Standardmäßig schalten moderne CPUs in den powersave-Modus, was Latenz-Spikes von 5–15 ms verursacht:
apt install linux-cpupower -y
cpupower frequency-set -g performance
echo 'GOVERNOR="performance"' | tee /etc/default/cpupower
systemctl enable --now cpupower
Optional kannst du mit isolcpus=2-5 nohz_full=2-5 rcu_nocbs=2-5 in der GRUB-Kommandozeile CPU-Kerne exklusiv für CS2 reservieren und den Scheduler-Tick deaktivieren. Das reduziert Jitter messbar um 20–40 %.
Die server.cfg liegt unter game/csgo/cfg/server.cfg. Für kompetitives Spiel (5v5, MR12) empfehlen wir folgende Basis:
hostname "HOSTAZAR CS2 | 128 Tick | DE"
rcon_password "SICHERES_PASSWORT_HIER"
sv_password ""
sv_lan 0
sv_cheats 0
sv_maxrate 0
sv_minrate 128000
sv_maxupdaterate 128
sv_minupdaterate 64
sv_maxcmdrate 128
sv_mincmdrate 64
sv_client_min_interp_ratio 1
sv_client_max_interp_ratio 2
sv_pausable 0
sv_allow_votes 1
mp_autoteambalance 0
mp_maxrounds 24
mp_roundtime 1.92
mp_freezetime 15
mp_buytime 20
mp_c4timer 40
mp_overtime_enable 1
mp_overtime_maxrounds 6
mp_match_can_clinch 0
mp_team_intro_time 6.5
mp_halftime 1
mp_halftime_duration 15
mp_solid_teammates 1
mp_forcecamera 1
mp_spectators_max 8
mp_limitteams 0
mp_warmuptime 60
mp_warmup_pausetimer 0
mp_endmatch_votenextmap 0
mp_match_end_restart 1
ammo_grenade_limit_total 4
ammo_grenade_limit_flashbang 2
sv_infinite_ammo 0
sv_deadtalk 1
sv_talk_enemy_dead 0
sv_talk_enemy_living 0
sv_full_alltalk 0
sv_auto_full_alltalk_during_warmup_half_end 1
Die Rate-Werte sind der kritischste Teil. sv_maxrate 0 bedeutet "unbegrenzt" und ist für moderne Server mit Gigabit-Uplink korrekt. sv_minrate 128000 (128 KB/s) verhindert, dass Spieler mit schlechter Verbindung das Spielgeschehen verlangsamen. Die Updaterates sollten exakt der Tickrate entsprechen (128/128), damit keine Inputs verworfen werden.
Die sv_client_min_interp_ratio 1 ist für 128 Tick optimal: Sie erlaubt Spielern mit stabiler Verbindung, mit minimaler Interpolation zu spielen, was den Peeker's Advantage reduziert. Wer auf maximalen Kompetitivitäts-Faktor setzt, kann zusätzlich sv_client_predict 1 und sv_client_cmdrate_difference 0 setzen.
Auf Servern mit mehreren Instanzen solltest du den ausgehenden Traffic klassifizieren, damit CS2-Pakete bevorzugt behandelt werden. Mit tc (Traffic Control) richtest du eine Prioritätsklasse ein:
tc qdisc add dev eth0 root handle 1: htb default 20
tc class add dev eth0 parent 1: classid 1:1 htb rate 1000mbit
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 800mbit ceil 1000mbit prio 1
tc class add dev eth0 parent 1:1 classid 1:20 htb rate 200mbit ceil 1000mbit prio 2
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \
match ip dport 27015 0xffff flowid 1:10
Wichtiger ist jedoch die Interrupt-Affinity. Bei Multi-Gigabit-Netzwerkkarten (Intel X710, Mellanox ConnectX-5) verteilen IRQs die Last über mehrere Kerne. Mit ethtool -L eth0 combined 4 reduzierst du die Queues auf vier und bindest sie mit irqbalance oder manuell an dedizierte Kerne.
Prüfe regelmäßig den UDP-Puffer-Status mit netstat -su oder ss -u -a. Steigende Werte bei "packet receive errors" oder "receive buffer errors" deuten auf zu kleine Buffer oder überlastete NIC hin. Bei 128 Tick und 20 Spielern fließen etwa 3–5 MBit/s pro Instanz durch die Leitung.
Ein oft übersehener Punkt: IPv6. CS2 unterstützt IPv6 nur eingeschränkt. Deaktiviere es auf dem Server-Interface, um unnötige Verbindungsversuche zu vermeiden: sysctl -w net.ipv6.conf.all.disable_ipv6=1.
Für Community-Server sind SourceMod (aktuell 1.12+) und Metamod:Source (2.0+) weiterhin Standard. Beachte: CS2 nutzt eine völlig neue Engine-Basis, weshalb viele CS:GO-Plugins nicht mehr funktionieren. Kompatible Plugins findest du auf sourcemod.net und im AlliedMods-Forum.
Plugin-Empfehlungen für Performance und Spielkomfort:
Warnung: Jedes Plugin kostet CPU-Zeit im Tick-Thread. Bei 128 Tick solltest du maximal 8–10 Plugins gleichzeitig aktiv haben. Nutze sm plugins list und sm prof, um CPU-Fresser zu identifizieren. Der SourceMod Profiler zeigt dir pro Plugin die verbrauchten Millisekunden pro Tick – alles über 0,5 ms pro Plugin ist problematisch.
Containerisierung erleichtert Updates und Multi-Instanz-Betrieb. Das beliebteste Image ist joedwards32/cs2. Eine docker-compose.yml für eine 128-Tick-Instanz:
services:
cs2-1:
image: joedwards32/cs2:latest
container_name: cs2-1
environment:
SRCDS_TOKEN: "DEIN_STEAM_TOKEN"
CS2_SERVERNAME: "HOSTAZAR #1 | 128 Tick"
CS2_PORT: 27015
CS2_RCONPW: "sicheresPasswort"
CS2_MAXPLAYERS: 12
CS2_TICKRATE: 128
CS2_GAMEALIAS: "competitive"
CS2_STARTMAP: "de_dust2"
CS2_ADDITIONAL_ARGS: "-norestart"
ports:
- "27015:27015/udp"
- "27015:27015/tcp"
volumes:
- ./cs2-data:/home/steam/cs2-dedicated/
cpus: "2.0"
mem_limit: 4g
restart: unless-stopped
Setze cpus: "2.0" und mem_limit: 4g, um Ressourcen sauber zu begrenzen. Ohne Limits kann eine einzige Instanz bei einem Map-Load alle Kerne fressen und andere Instanzen ausbremsen. Nutze cpuset statt cpus, wenn du harte Kern-Bindung willst: cpuset: "2-3".
Für Multi-Instanz-Setups empfiehlt sich ein gemeinsames Workshop-Volume. CS2 lädt Workshop-Maps in game/csgo/workshop/ – bei fünf Instanzen sind das schnell 30 GB. Ein Read-Only-Mount desselben Verzeichnisses spart Speicher und Bandbreite.
Ohne Monitoring fliegst du blind. Die wichtigsten Metriken für einen CS2-Server:
stats im Server-Console sichtbarnetstat -su | grep errorsmpstat -P ALL 1mtr zu typischen Spieler-IPsFür kontinuierliches Monitoring empfehlen wir Netdata oder Prometheus + Grafana. Netdata installiert sich in 30 Sekunden und zeigt dir CPU, RAM, Netzwerk und Disk in Echtzeit. Für Multi-Server-Setups lohnt sich ein zentrales Grafana-Dashboard mit Node-Exporter.
CS2-seitig kannst du mit sv_log_onefile 0 und sv_logfile 1 detaillierte Logs schreiben. Analysiere diese mit cs2-log-parser oder Logstash, um wiederkehrende Lags, Map-Crashes oder verdächtige Spieler zu identifizieren.
Für die meisten Admins ist die Wahl zwischen fertigem Gameserver-Hosting und einem eigenen Root-Server die zentrale Kostenfrage. Eine Übersicht (Stand Q1 2026):
| Anbieter / Modell | Specs | Preis/Monat | Geeignet für |
|---|---|---|---|
| Nitrado CS2 12 Slots | Shared, 128 Tick | 8,99 € | Einsteiger, Clans |
| 4Netplayers CS2 16 Slots | Shared, 128 Tick | 11,99 € | Public-Server |
| ZAP-Hosting CS2 20 Slots | Shared, 128 Tick | 14,50 € | Community |
| Hetzner Cloud CCX23 | 4 vCPU, 16 GB, NVMe | 26,00 € | 2–3 Instanzen |
| Hetzner AX42 (dediziert) | Ryzen 7 7700, 64 GB | 47,00 € | 4–6 Instanzen |
| Hetzner AX52 (dediziert) | Ryzen 9 7900, 128 GB | 67,00 € | 6–10 Instanzen |
Die Rechnung ist eindeutig: Ab drei CS2-Instanzen ist ein dedizierter Root-Server günstiger und deutlich performanter. Ein AX42 für 47 € ersetzt sechs Gameserver-Slots im Wert von ~54 € – bei voller Hardware-Kontrolle, eigenem Kernel-Tuning und ohne geteilte CPU. Für einen einzelnen Clan-Server mit 10 Slots ist Nitrado oder 4Netplayers aber bequemer und günstiger.
Wichtig: Achte beim Root-Server auf unmetered Traffic (Hetzner: 20 TB bei dedizierten Servern) und DDoS-Schutz. CS2-Server werden häufig Opfer von UDP-Floods – ohne Schutz ist dein Server binnen Sekunden offline.
Die fünf häufigsten Probleme, die wir bei CS2-Setups sehen:
sv_setsteamaccount Token. Registriere den Server unter steamcommunity.com/dev/managegameservers.net.core.rmem_max.sm prof und mpstat.sv_workshop_allow_other_maps 1 setzen.sv_minrate 128000 und sv_minupdaterate 64.Für tiefes Debugging nutze net_graph 1 im Client, um die tatsächliche Updaterate zu sehen. Wenn die Client-Rate unter 128 liegt, obwohl der Server 128 Tick fährt, stimmt die Config nicht.
Ja, aber der Vorteil ist geringer als in CS:GO. Das Subtick-System verarbeitet Inputs zeitunabhängig, weshalb 64 Tick auf offiziellen Servern kaum Nachteile bringt. Bei Community-Servern mit kompetitivem Anspruch ist 128 Tick dennoch Standard, weil die Updaterate für Clients höher ist und Peeker's Advantage reduziert wird – vorausgesetzt, die CPU schafft die doppelte Last.
Faustregel: 2 dedizierte CPU-Kerne pro 128-Tick-Instanz mit 10 Slots. Ein Hetzner AX42 (Ryzen 7 7700, 8C/16T) stemmt 4–6 Instanzen, ein AX52 (Ryzen 9 7900, 12C/24T) bis zu 10. RAM: 2 GB pro Instanz plus 4 GB für das OS. NVMe ist Pflicht.
Die Rate-Werte: sv_maxrate 0, sv_minrate 128000, sv_maxupdaterate 128, sv_minupdaterate 64. Dazu sv_client_min_interp_ratio 1 und sv_client_max_interp_ratio 2. Diese Werte bestimmen direkt Hit-Registrierung und Peeker's Advantage.
Für reine Public-Server nicht zwingend. SourceMod (1.12+) und Metamod (2.0+) sind aber Voraussetzung für Match-Management (Get5), Practice-Mode und Admin-Tools. Jedes Plugin kostet Tick-Zeit – halte die Liste unter 10 Plugins.
Ab drei CS2-Instanzen ja. Ein Hetzner AX42 für 47 €/Monat ersetzt sechs Gameserver-Slots (~54 €) bei deutlich besserer Performance und voller Kernel-Kontrolle. Für einen einzelnen 10-Slot-Clan-Server ist Nitrado (8,99 €) oder 4Netplayers (11,99 €) günstiger und wartungsfreier.