Wydajność serwera gry: jak diagnozować spadki TPS i obciążenie

Wydajność serwera gry nie bierze się z jednego parametru – to wypadkowa procesora, pamięci RAM, dysku i sposobu, w jaki silnik gry liczy każdą klatkę świata. Kiedy gracze zaczynają zgłaszać szarpanie, teleportujące się moby czy opóźnione strzały, winny rzadko jest jeden element – zwykle to kaskada: za dużo encji, za mało wątków procesora, dysk niepotrzebnie obciążony logami. Ten artykuł pokazuje, jak czytać te sygnały niezależnie od tytułu, który hostujesz.

Wydajność serwera gry – jak działa pętla tick i co to jest TPS

Większość silników gier (Minecraft, ARK, Rust, Valheim) działa w oparciu o pętlę tick – cykl, w którym serwer liczy fizykę, ruch mobów, odradzanie zasobów i synchronizację z klientami. W Minecrafcie domyślnie serwer dąży do 20 ticków na sekundę (TPS). Jeśli obliczenie jednego ticka trwa dłużej niż 50 ms, serwer „spóźnia się" i TPS spada poniżej 20 – gra zaczyna się jąkać, mimo że gracze mają dobre łącze.

W grach bez jawnego licznika TPS (Rust, ARK, Palworld) mechanizm jest analogiczny – silnik ma budżet czasu na klatkę symulacji i jeśli obciążenie CPU przekracza ten budżet, pojawia się rubber-banding, opóźnione odradzanie zwierzyny czy zacinające się budowanie baz. Różnica jest głównie w narzędziach diagnostycznych, nie w samej fizyce problemu.

Kluczowy jest fakt, że pętla tick w zdecydowanej większości silników gier jest jednowątkowa dla logiki świata – dlatego częstotliwość rdzenia procesora (IPC, zegar) liczy się bardziej niż sama liczba rdzeni. To dlatego procesory Ryzen o wysokim taktowaniu radzą sobie lepiej z symulacją dużej liczby encji niż procesory z wieloma, ale wolniejszymi rdzeniami.

Jeśli chcesz zobaczyć te mechanizmy w praktyce na panelu z podglądem konsoli na żywo i gotową instalacją modów, sprawdź hosting Minecraft – tam TPS i obciążenie widać od razu po starcie serwera.

Diagnoza spadków płynności: RAM, CPU i dysk pod lupą

Spadek TPS czy ogólnej płynności rozgrywki zawsze ma źródło w jednym z trzech obszarów: procesorze, pamięci lub operacjach dyskowych. Poniżej konkretne sygnały, po których rozpoznasz, co faktycznie dławi serwer.

Procesor (CPU) – wąskie gardło numer jeden

Jeśli wykres obciążenia rdzenia obsługującego główny wątek gry stale siedzi w okolicach 90-100%, a TPS spada mimo wolnej pamięci RAM – to CPU jest limiterem. Typowe przyczyny:

• zbyt duża liczba aktywnych encji (moby, zwierzęta, pojazdy, NPC w FiveM),
• mody lub pluginy wykonujące ciężkie obliczenia co tick (np. skrypty ekonomii, redstone w dużej skali),
• zbyt duży promień renderowania/symulacji (view-distance, simulation-distance).

Pamięć RAM – nie tylko „zabraknie"

Brak wolnej RAM to oczywisty problem, ale równie częsty jest nieprawidłowo skonfigurowany garbage collector w JVM (Minecraft Java). Źle dobrane flagi powodują długie „GC pauses" – serwer na chwilę zamraża się całkowicie, co w logach widać jako nagły, krótki, ale drastyczny spadek TPS.

java -Xms6G -Xmx6G -XX:+UseG1GC -XX:+ParallelRefProcEnabled \
-XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions \
-jar paper.jar nogui

Dysk i operacje I/O

Dysk rzadko jest pierwszą przyczyną spadku TPS, ale potrafi go pogłębiać – szczególnie przy automatycznych zapisach świata (autosave) na dużych mapach. Na klasycznym dysku talerzowym zapis chunków blokuje na chwilę inne operacje; na SSD NVMe ten efekt jest praktycznie niezauważalny, dlatego przy dużych światach i wielu graczach różnica w odczuwalnej płynności bywa wyraźna.

Objaw	Najbardziej prawdopodobna przyczyna	Co sprawdzić
TPS spada stopniowo w ciągu godzin	przyrost encji/przedmiotów na mapie	liczba moby/itemów, timings report
Nagłe, krótkie zamrożenie co kilka minut	garbage collection JVM lub autosave	flagi -Xmx/-Xms, interwał save-interval
Stałe 100% CPU na jednym rdzeniu	zbyt ciężkie mody/pluginy	profiler, logi startowe pluginów
Wysoka latencja mimo niskiego CPU	sieć, trasa do węzła	ping, traceroute, MTU

Narzędzia do pomiaru wydajności serwera gry

Zanim zaczniesz usuwać mody na chybił trafił, zbierz dane. Poniżej zestaw komend i narzędzi, które pozwalają odróżnić symptom od przyczyny.

Na poziomie gry (Minecraft Paper/Spigot/Forge)

/tps
/forge tps
/timings report

Komenda /timings report generuje link z rozbiciem obciążenia na konkretne pluginy i funkcje – to najszybszy sposób, by zobaczyć, który plugin zjada czas ticka.

Na poziomie panelu i systemu

W panelu Pterodactyl masz podgląd zużycia CPU, RAM i ruchu sieciowego w czasie rzeczywistym bezpośrednio z poziomu przeglądarki, bez potrzeby łączenia się przez SSH. Jeśli jednak zarządzasz maszyną samodzielnie:

htop
docker stats
systemctl status pterodactyl-wings
journalctl -u pterodactyl-wings -f

htop pokaże, czy obciążenie jest skupione na jednym rdzeniu (typowe dla gier z jednowątkową pętlą tick), a docker stats przyda się, gdy kontener gry ma ustawiony limit zasobów i warto sprawdzić, czy go nie osiąga.

Monitoring sieci i opóźnień

ping -c 20 adres_serwera
traceroute adres_serwera
mtr adres_serwera

Wysoki TPS i niska latencja na poziomie serwera nie gwarantują płynnej rozgrywki, jeśli po drodze występują zgubione pakiety – dlatego warto rozróżniać opóźnienie generowane przez serwer od opóźnienia sieciowego, zanim zaczniesz zmieniać konfigurację gry.

Optymalizacja i utrzymanie stabilnej wydajności na co dzień

Diagnoza to połowa pracy – druga połowa to regularne nawyki administracyjne, które zapobiegają powrotowi problemu.

Konfiguracja pod kontrolą

• ogranicz view-distance i simulation-distance do wartości faktycznie potrzebnej graczom,
• pregeneruj chunki poza godzinami szczytu zamiast generować je „na żywo" pod stopami graczy,
• ustaw rozsądny limit encji na obszar (np. entity-activation-range w Paper),
• aktualizuj mody i pluginy – wiele spadków wydajności znika po jednej aktualizacji wydanej przez autora.

Rutyna administracyjna

Zaplanuj restart serwera co 12-24h na dużych instalacjach modowych – to czyści pamięć fragmentaryzowaną przez JVM i resetuje nagromadzone encje. Ustaw też regularne, automatyczne kopie zapasowe przed każdą większą zmianą konfiguracji lub aktualizacją mod packa, żeby cofnięcie się do stabilnej wersji było kwestią minut, nie godzin odtwarzania z pamięci.

systemctl restart your-game-service
cp -r /srv/game/world /srv/backups/world_$(date +%F_%H%M)

Bezpieczeństwo jako element stabilności

Spadek TPS bywa też skutkiem ataku lub nadużycia – boty spamujące komendy, exploit tworzący tysiące encji czy nieautoryzowany dostęp do RCON potrafią zdusić wydajność szybciej niż jakikolwiek legalny ruch graczy. Silne hasło RCON, whitelist, a na poziomie systemu fail2ban i reguły ufw ograniczające dostęp tylko do niezbędnych portów to podstawa – warstwa anti-DDoS po stronie infrastruktury chroni przed atakami wolumetrycznymi, ale nie zastępuje higieny konfiguracji samej gry.

ufw allow 25565/tcp
ufw allow 25565/udp
ufw enable

Więcej o konfiguracji konkretnych tytułów znajdziesz na Wszystkie nasze serwery gier, a jeśli zarządzasz infrastrukturą samodzielnie, panel do własnej instalacji opisuje VPS Pterodactyl.

Spadki płynności rzadko mają jedną przyczynę – to zwykle splot obciążenia CPU, źle dobranej pamięci i nawyków konfiguracyjnych. Regularna diagnoza, prosty monitoring i kilka nawyków administracyjnych pozwalają utrzymać stabilną rozgrywkę na dłużej, zanim gracze w ogóle zauważą problem.

FAQ

Dlaczego TPS spada mimo niskiego zużycia RAM?

Ponieważ pętla tick w większości silników gier liczy logikę świata na jednym wątku – problemem jest wtedy obciążenie pojedynczego rdzenia CPU, a nie ilość dostępnej pamięci. Sprawdź /timings report lub htop, by zlokalizować, co dokładnie zajmuje czas procesora.

Czy więcej rdzeni procesora rozwiąże problem niskiego TPS?

Nie zawsze – logika świata w wielu grach jest jednowątkowa, więc liczy się głównie wysoka częstotliwość pojedynczego rdzenia, a nie łączna liczba rdzeni. Dodatkowe wątki pomagają innym procesom (sieć, kompresja chunków), ale nie przyspieszą bezpośrednio samej pętli tick.

Jak sprawdzić, czy spadek wydajności wynika z sieci, a nie z serwera gry?

Porównaj wynik /tps lub timingów gry z wynikiem ping i mtr do adresu serwera. Jeśli TPS jest stabilne, a opóźnienia odczuwalne tylko u części graczy, problem leży po stronie trasy sieciowej, nie konfiguracji serwera.