Serwer Minecraft laguje: znajdź przyczynę i usuń lagi

„Serwer laguje” to najczęstsze zgłoszenie, jakie trafia do wsparcia każdego operatora serwerów gier, a zarazem najmniej przydatne. Za tym jednym zdaniem kryją się co najmniej trzy zupełnie różne problemy techniczne, które nie mają ze sobą nic wspólnego i które usuwa się zupełnie innymi metodami. Kto zgaduje zamiast mierzyć, przez tygodnie kręci parametrem view-distance i flagami Javy, podczas gdy prawdziwą przyczyną jest zepsuty ciąg hopperów w piwnicy jednego z graczy.

Ten poradnik prowadzi cię w kolejności, która naprawdę działa: najpierw rozróżnienie, potem pomiar, potem przyczyna, na końcu środek zaradczy. A na sam koniec pytanie, które pomija większość instrukcji: po czym w ogóle poznasz, że problem faktycznie zniknął.

Dwa objawy, które odczuwa się identycznie

Istnieją dwa zupełnie różne rodzaje lagów, a do tego trzeci przypadek, który z serwerem nie ma nic wspólnego.

Lag serwera oznacza, że serwer nie wyrabia się już ze swoimi 20 krokami obliczeniowymi na sekundę. Wolniej działa sam świat gry. Moby stoją albo drgają, piece pracują dłużej, wykopane bloki pojawiają się z powrotem, a stojaki na zbroję unoszą się z opóźnieniem.

Lag sieciowy oznacza, że serwer liczy bez zarzutu, ale pakiety między graczem a serwerem idą za długo albo giną po drodze. Gracza cofa w trakcie biegu (rubberbanding), ciosy nie trafiają, czat przychodzi z opóźnieniem, ale moby dookoła poruszają się zupełnie płynnie.

Lag klienta to trzeci przypadek: za mało klatek na sekundę na komputerze gracza, najczęściej przez shadery, dużą odległość widzenia ustawioną w kliencie albo zbyt małą przydzieloną pamięć RAM. Na serwerze tego nie widać i nie da się tego tam naprawić.

Jedna reguła sprawdza się niemal zawsze: jeśli problem dotyczy wszystkich naraz, winny jest serwer. Jeśli dotyczy pojedynczych osób, winne jest łącze. Jeden wyjątek tę regułę łamie: całkowicie przeciążony serwer potwierdza pakiety sieciowe z opóźnieniem i dodatkowo podbija pingi. Dlatego zawsze mierzy się jedno i drugie.

Pierwszy test zajmuje 60 sekund

Połącz się przez SSH z serwerem i otwórz konsolę serwera. Jeśli usługa nie działa jeszcze porządnie w tle, pomoże wpis Automatyczne uruchamianie serwera Minecraft.

W Paperze, Purpurze i Folii od wersji 1.21 profiler Spark jest już wbudowany w serwer, więc nie trzeba niczego instalować. W grze albo w konsoli:

spark tps
spark health --memory --network

Wynik polecenia spark tps pokazuje cztery okna czasowe (5 sekund oraz 1, 5 i 15 minut), a do tego czasy ticków jako minimum, medianę, 95. percentyl i maksimum.

Na czystej Vanilli bez pluginów dostępne jest /tick query. Polecenie podaje docelową częstotliwość oraz średni czas ticka. Dodatkowo F3 razem z 2 wyświetla operatorom wykres ticków.

Konsola często zdradza problem sama z siebie. Czytelnicy zwykle szukają dokładnie takich wierszy:

[Server thread/WARN]: Can't keep up! Is the server overloaded? Running 2123ms or 42 ticks behind
[Server thread/WARN]: Can't keep up! Did the system time change, or is the server overloaded? Running 2340ms behind

Ten komunikat znaczy po prostu tyle: serwer potrzebował na jeden krok obliczeniowy wyraźnie więcej niż dozwolone 50 milisekund i musi pomijać ticki. Pojedynczy wpis po restarcie albo po generowaniu świata jest normalny. Jeden co kilka minut to już prawdziwy problem.

Równolegle sprawdź stronę systemową. mpstat nie należy do podstawowego wyposażenia żadnego ze sprawdzonych systemów, pochodzi z pakietu sysstat i trzeba go jednorazowo doinstalować:

apt-get install -y sysstat procps
uptime
free -h
mpstat 1 3

W AlmaLinuksie, Rocky Linuksie i Oracle Linuksie pierwszy wiersz brzmi dnf -y install sysstat procps-ng iproute, bo tam pakiet z narzędziami free, uptime, top i vmstat nazywa się nie procps, tylko procps-ng.

W wyniku polecenia mpstat najciekawsza jest kolumna %steal. Wartości utrzymujące się trwale powyżej 5 procent oznaczają, że maszyna wirtualna czeka na czas procesora zajęty przez innego gościa. To nie jest wtedy problem Minecrafta, tylko problem z zasobami sprzętu leżącego pod spodem.

Jedno zastrzeżenie do tych trzech poleceń: na własnym serwerze albo na VPS pokazują dokładnie to, co chcesz wiedzieć. Jeśli natomiast twój serwer działa w kontenerze, na przykład w panelu do gier w rodzaju Pterodactyl, to free, uptime, vmstat i mpstat zgłaszają wartości systemu gospodarza, a nie twojej instancji. Widzisz wtedy cudze obciążenie i cudzą pamięć. W takim wypadku zdaj się na wskazania panelu i na spark health.

Jak poprawnie czytać TPS i MSPT

Serwer Minecraft liczy 20 ticków na sekundę, więc każdy tick ma budżet 50 milisekund. MSPT (milisekundy na tick) jest wartością bardziej wymowną, bo pokazuje problemy, zanim TPS w ogóle zaczną spadać. Serwer z 20,0 TPS i 46 ms MSPT pracuje na absolutnej granicy i wywróci się przy pierwszym graczu, który wejdzie w nowy obszar.

• MSPT poniżej 30 ms: zdrowo, jest zapas.
• MSPT od 30 do 45 ms: ciasno, ale grywalnie. Czas działać.
• MSPT powyżej 50 ms: TPS muszą spaść, gracze to zauważą.

Ważniejszy od średniej jest rozkład. Mediana 18 ms przy maksimum 900 ms oznacza skoki: pojedyncze kosztowne zdarzenia, takie jak automatyczny zapis, generowanie chunków albo zadanie pluginu uruchamiane co minutę. Mediana 60 ms oznacza natomiast stałe obciążenie, czyli zbyt dużo tickowanej zawartości jak na dostępną moc obliczeniową. Środki zaradcze są w obu przypadkach zupełnie inne.

Punkt, który doradcy sprzętowi chętnie pomijają: główny tick Minecrafta działa w jednym wątku. Wczytywanie chunków i obsługa sieci zostały wyniesione osobno, ale sama symulacja świata już nie. Serwer z 32 rdzeniami i słabą wydajnością pojedynczego rdzenia jest dla Minecrafta wolniejszy niż serwer z 8 szybkimi rdzeniami. Więcej rdzeni pomaga dopiero wtedy, gdy działa na nich kilka instancji serwera.

Spark: od podejrzenia do dowodu

Timings, przez lata narzędzie standardowe, w Paperze od serii 1.21 pracuje w trybie jałowym i nie dostarcza już użytecznych danych. Kto dziś wciąż wrzuca linki z Timings, nie mierzy niczego. Następcą jest Spark, wbudowany w Paper. Dla Fabrica, Forge i NeoForge dostępny jest jako mod, a dla Velocity i BungeeCord jako osobna odmiana.

Kluczowa zasada postępowania: profiluj wtedy, gdy problem faktycznie występuje. Profil pustego serwera o trzeciej w nocy jest nic niewart.

spark profiler start --timeout 300
spark profiler stop

Przy skokach, które pojawiają się tylko od czasu do czasu, warto celowo odfiltrować złe ticki:

spark profiler start --only-ticks-over 60 --timeout 600

Zapisywane są wtedy tylko ticki, które trwały dłużej niż 60 milisekund. Dokładnie te gracze odczuwają. Reszta zostaje pominięta i nie zaciemnia obrazu.

Przy czytaniu wykresu płomieniowego początkujący popełniają niemal zawsze ten sam błąd: patrzą na najgłębsze rozgałęzienie. Prawidłowo patrzy się na szerokość słupków leżących bezpośrednio pod tickiem serwera. Wpis z 3 procentami nie ma znaczenia, nawet jeśli schodzi sto poziomów w głąb. Reguła praktyczna: pojedynczy plugin z udziałem ponad 15 procent w czasie ticka to kandydat na winowajcę. Bardzo szerokie wpisy wokół encji blokowych wskazują na redstone i hoppery, a szerokie wpisy wokół wczytywania chunków na generowanie świata.

Uwaga na temat poufności: wgrany raport jest publicznie dostępny pod swoim linkiem i zawiera informacje o systemie, ścieżki, parametry startowe oraz pełną listę pluginów. Przekazuj ten link tylko osobom, którym powierzyłbyś takie dane. Z opcją --save-to-file profil zostaje lokalnie.

Typowi sprawcy

Redstone i farmy

Hoppery (leje) są zdecydowanie najdroższymi blokami w grze, bo każdy z nich przy każdym ticku sprawdza, czy coś nad nim leży. Sortownia z 400 hopperami kosztuje więcej czasu obliczeń niż sto mobów. Do tego dochodzą zegary na obserwatorach, które chodzą także wtedy, gdy nikogo nie ma w pobliżu, o ile chunk jest symulowany. Jeśli Spark spędza podejrzanie dużo czasu w encjach blokowych, szukaj dokładnie takich konstrukcji.

Encje

W Paperze polecenie /paper entity list wypisuje encje w podziale na świat i typ, razem ze współrzędnymi chunków. To najszybsza droga do problematycznego obszaru. Typowe znaleziska: kilka tysięcy stosów przedmiotów w farmie mobów, hodowla z 300 krowami, zapomniany teren pełen wystrzelonych strzał.

Sensowne przeciwdziałanie w pliku spigot.yml: obniż entity-activation-range dla zwierząt i potworów (na przykład zwierzęta z 32 na 16, potwory z 32 na 24) oraz lekko podnieś merge-radius dla przedmiotów i kul doświadczenia, żeby istniało mniej pojedynczych obiektów. W pliku paper-world-defaults.yml parametr entity-per-chunk-save-limit ogranicza, ile obiektów danego typu w ogóle zostaje zapisanych na jeden chunk.

Wczytywanie chunków

Gracz z elytrą albo na szybkim koniu zmusza serwer do nieustannego tworzenia nowego terenu. Generowanie świata to najdroższa pojedyncza operacja w ogóle. To samo dzieje się przy pierwszym wejściu do Netheru albo po powiększeniu granicy świata. Rozwiązaniem nie jest żaden wpis w konfiguracji, tylko wstępne generowanie, a to jest na tyle ważne, że ma niżej własny rozdział.

Pluginy

Jeśli Spark wskaże konkretny plugin, sprawa jest jasna. Jeśli nie, zostaje tylko wyszukiwanie połówkowe: wyłącz połowę pluginów, zmierz, a potem dziel dalej na pół tę połowę, która obciąża serwer. Przy 32 pluginach to pięć restartów zamiast 32. Wcześniej koniecznie zrób kopię zapasową, bo pluginy zapisujące dane świata mogą po usunięciu zostawić zawartość, która bez nich przestaje działać.

Wstępne generowanie chunków, zanim wejdą na nie gracze

To najskuteczniejsze pojedyncze działanie z całego tego artykułu, a zarazem najczęściej pomijane. Powód tkwi w tym, jak działa Minecraft: wczytanie z dysku chunka, który już istnieje, nie kosztuje prawie nic. Utworzenie nowego chunka oznacza natomiast mapę wysokości, biomy, rozmieszczenie rud, jaskinie, struktury i obliczenia światła, a duża część tego dzieje się w głównym wątku. Dokładnie tam, gdzie musi też powstawać 20 ticków na sekundę.

Dlatego lagi pojawiają się zwykle wtedy, gdy ktoś odlatuje na elytrze albo buduje tor kolejki w nieznane: serwer tworzy świat, choć w tym samym czasie ma liczyć rozgrywkę. Kto raz wygeneruje świat z wyprzedzeniem aż do granicy świata, zamienia kosztowne obliczenia w tanie czytanie z dysku.

Chunky, narzędzie pierwszego wyboru

Chunky to dziś standardowy generator wstępny. Działa jako plugin w Paperze, Spigocie i Purpurze oraz jako mod w Fabricu i Forge. Przebieg jest na wszystkich platformach taki sam:

/chunky world world
/chunky center 0 0
/chunky radius 5000
/chunky start

Promień podaje się w blokach i powinien odpowiadać granicy świata. Postęp oraz szacowany czas do zakończenia Chunky podaje sam; poleceniami /chunky pause i /chunky continue można przebieg w każdej chwili wstrzymać i wznowić, także po restarcie.

Nether i End to osobne światy i trzeba je generować wstępnie każdy z osobna. W Paperze i Spigocie nazywają się domyślnie tak:

/chunky world world_nether
/chunky radius 1000
/chunky start

Dla Netheru wystarczy mniejszy promień, bo jeden blok odpowiada tam ośmiu blokom w świecie górnym. Promień 1000 w Netherze pokrywa więc 8000 bloków świata górnego.

Co trzeba przy tym uwzględnić

• Czas. Promień 5000 bloków to około 78 milionów bloków powierzchni. Zależnie od sprzętu, modpacka i generatora świata trwa to od godziny do kilku dni. Modpacki z własnymi generatorami świata są wyraźnie wolniejsze od Vanilli.
• Miejsce na dysku. Wstępnie wygenerowany świat szybko zajmuje kilka gigabajtów. Sprawdź wcześniej, ile masz wolnego, bo inaczej dysk zapełni się w trakcie przebiegu, a to uderzy w serwer mocniej niż jakikolwiek lag. Jak to sprawdzić i posprzątać, opisuje wpis Dysk pełny: jak znaleźć i zwolnić miejsce.
• Moment. Generuj wstępnie na pustym serwerze, nie w trakcie normalnej gry. Podczas przebiegu tickrate jest zgodnie z oczekiwaniami kiepski i nie jest to błąd. Sens całej operacji polega przecież właśnie na tym, żeby wyjąć to obciążenie z czasu gry.
• Ustaw granicę świata. Bez granicy ktoś kiedyś wyjdzie poza wygenerowany obszar i wszystko zacznie się od nowa. Ustaw granicę na ten sam promień, który wygenerowałeś wstępnie.

Sprzątanie po fakcie

Jeśli świat już się rozrósł i zawiera obszary, w które nikt już nie wchodzi, Chunky usunie chunki leżące poza granicą świata:

/chunky trim

Zmniejsza to świat, a razem z nim odczuwalnie także kopie zapasowe. Wcześniej koniecznie wykonaj kopię zapasową, bo usunięte chunki zostaną przy kolejnym wejściu wygenerowane od nowa, a wszystko, co gracze tam zbudowali, przepadnie.

Gdy Chunky nie wchodzi w grę

Na starszych serwerach często wciąż znajdziesz WorldBorder z poleceniem /wb fill. Spełnia ten sam cel, ale projekt od lat jest praktycznie bez opieki, więc dla aktualnych wersji serwera pewniejszym wyborem jest Chunky. W obu przypadkach sprawdź przed instalacją, czy oferowana wersja faktycznie pasuje do twojej wersji serwera.

view-distance i simulation-distance

Te dwie wartości w pliku server.properties są nieustannie mylone.

• view-distance określa, jak daleko chunki są wysyłane do klienta. Kosztuje przepustowość łącza i trochę pamięci.
• simulation-distance określa, jak daleko serwer przelicza encje, redstone i aktualizacje bloków. Kosztuje czas procesora w głównym ticku.

Chunki leżące między granicą symulacji a granicą widzenia są wyświetlane, ale po stronie serwera pozostają zamrożone. Koszt rośnie kwadratowo: przy view-distance=10 to 21 razy 21, czyli 441 chunków na gracza.

Sprawdzone wartości wyjściowe dla sieci survivalowej z 10 do 30 graczami:

view-distance=8
simulation-distance=5

Jeśli trafisz jeszcze na poradniki z no-tick-view-distance: ta opcja Papera jest przestarzała. Mojang wprowadził w wersji 1.18 simulation-distance i rozwiązał ten sam problem oficjalnie. Kto ustawia dziś starą wartość, nie osiąga niczego.

O cenie niskich wartości mówi się rzadko: przy simulation-distance poniżej 4 rozsypują się farmy AFK, spawn mobów zachowuje się inaczej, piece w sąsiednim chunku przestają pracować, a zegary z redstone stają. Kto ma społeczność mocno nastawioną na farmy, oszczędza tu w złym miejscu i zamienia problem techniczny na problem z graczami. Schodź w dół po jednym stopniu i mierz po każdym kroku.

Sprzątanie bez niszczenia świata

Każda ingerencja w dane świata zaczyna się od kopii zapasowej przy zatrzymanym serwerze. Bez kompromisów, bez wyjątków:

tar -czf backup-swiata.tar.gz world world_nether world_the_end

Potem warto rzucić okiem na rozmiar danych regionów:

du -sh world/region

Światy rosnące przez lata zawierają często setki megabajtów terenu, nad którym jeden jedyny gracz raz przeleciał. Te chunki nie kosztują czasu ticka, ale zajmują miejsce na dysku i wydłużają każdy zapis. Gdy miejsca zaczyna brakować, pomoże dodatkowo wpis Pełny dysk w Linuksie: jak zrobić porządek.

Regularne skoki rzędu sekund, pojawiające się dokładnie co pięć minut, to niemal zawsze automatyczny zapis. W pliku bukkit.yml interwałem steruje ticks-per.autosave, a w pliku paper-world-defaults.yml parametr max-auto-save-chunks-per-tick ogranicza, ile danych zapisuje się w jednym ticku. Mniejsza wartość rozkłada obciążenie, zamiast kumulować je w jednej chwili.

Dla małych, prywatnych serwerów od serii 1.21 dostępna jest w pliku server.properties opcja pause-when-empty-seconds. Jeśli wpiszesz tam wartość większą od zera, serwer po tym czasie bez graczy przestaje tickować świat. Na współdzielonym serwerze root oszczędza to odczuwalnie czasu procesora.

Gdy hamuje maszyna wirtualna Javy

Jeśli średni czas ticka pozostaje niski, ale nieregularnie skacze do kilkuset milisekund, winne bywa odśmiecanie pamięci w środowisku uruchomieniowym Javy. Sprawdzisz to bezpośrednio:

spark gcmonitor
spark heapsummary

Dwa rozpowszechnione błędy myślowe: większy heap nie jest automatycznie lepszy, bo duże sterty oznaczają dłuższe pauzy przy odśmiecaniu. I heap nigdy nie może być tak duży, żeby system operacyjny został zepchnięty do swapu. Swapujący serwer Minecraft jest wolny bez ratunku. Sprawdź to poleceniem vmstat 1 5: stałe wartości w kolumnach si i so to wyrok śmierci. Tło opisuje wpis Konfiguracja swapu i unikanie Out of Memory.

Ten komunikat jest objawem, a nie przyczyną:

java.lang.OutOfMemoryError: Java heap space

Zwiększenie heapu tylko przesuwa awarię w czasie, jeśli plugin przecieka pamięcią albo istnieją miliony encji.

Przy wersji Javy dystrybucje wyraźnie się różnią i właśnie na tym wykłada się wiele instalacji. Od Minecrafta 1.20.5 wymagana jest Java 21. Debian 12 dostarcza w standardowym repozytorium tylko OpenJDK 17, bez OpenJDK 21, a Debian 13 dostarcza 21 oraz 25, ale nie 17. Ubuntu 22.04 i 24.04 mają w repozytorium 17 i 21. Kto musi zostać na Debianie 12, instaluje Temurin z repozytorium Adoptium. Kroki opisuje wpis Instalacja Javy 21 na Debianie, a dla starszych wersji serwera Instalacja Javy 17 na Debianie.

Nie sięgaj przy tym po wygodny pakiet zbiorczy default-jre-headless. Zależnie od wydania wskazuje on na zupełnie inną wersję: Debian 13 i Ubuntu 24.04 dają w ten sposób Javę 21, Debian 12 daje Javę 17, a Debian 11 oraz Ubuntu 22.04 dają Javę 11. Instalacja wszędzie przechodzi bez błędu, ale na dwóch ostatnich serwer i tak nie wystartuje. Podawaj więc wersję wprost, czyli openjdk-21-jre-headless.

java -version
java -XX:+PrintFlagsFinal -version 2>/dev/null | grep -w MaxHeapSize

Fragment 2>/dev/null tłumi baner wersji, który maszyna wirtualna Javy wypisuje na wyjście błędów i który inaczej wylądowałby w środku wyniku. A grep -w MaxHeapSize zwraca dokładnie jeden wiersz, podczas gdy wyszukiwanie nieprecyzyjne znajduje dodatkowo SoftMaxHeapSize.

Gdy coś pójdzie nie tak i jak z tego wyjść

Serwer przerywa pracę z błędem watchdoga. W logu pojawia się wtedy informacja, że pojedynczy tick trwał 60 sekund i serwer został uznany za zawieszony. To nie jest usterka, tylko zabezpieczenie przed trwale zablokowanym procesem. Dołączony stacktrace jest na wagę złota: pokazuje dokładnie, na czym serwer utknął. Tym progiem steruje wartość max-tick-time w pliku server.properties. Wyłączenie jej niczego nie naprawia, zamienia tylko awarię w trwale zamrożony serwer.

Po zmianie konfiguracji jest gorzej. Właśnie dlatego obowiązuje najważniejsza reguła tej diagnostyki: zawsze tylko jedna zmiana na jeden pomiar i zanotowana wartość wyjściowa. Kto rusza jednocześnie view-distance, zasięgi encji i flagi Javy, nie będzie potem wiedział, co zadziałało.

Po awarii serwer już nie startuje. Najczęściej uszkodzony jest plik level.dat. W katalogu świata leży level.dat_old, którym możesz go nadpisać, gdy tylko zrobisz kopię zepsutego stanu. Przy uszkodzonych plikach regionów pomoże już tylko kopia zapasowa.

Wszystko zoptymalizowane, a lagi zostają. Sprawdź wtedy warstwę niżej: %steal w mpstat, swapowanie w vmstat oraz opóźnienia dysku. Jeśli czas ticka pozostaje wysoki, choć Spark nie pokazuje żadnego pojedynczego sprawcy powyżej 10 procent, to po prostu za dużo zawartości jak na zbyt słabą wydajność pojedynczego rdzenia. Pomoże wtedy rozdzielenie na kilka instancji albo większa moc obliczeniowa, a nie kolejna śrubka w konfiguracji.

Wysokie pingi mają tylko gracze, a serwer jest spokojny. Wtedy winna jest sieć. Największą różnicę robi tu lokalizacja z krótkimi trasami do graczy. Dla serwerów we Frankfurcie nad Menem typowe opóźnienia z Polski mieszczą się w niskich wartościach dwucyfrowych. Jeśli przerwy pojawiają się nagle i seriami, w tle może stać także atak, zobacz Ochrona serwera przed atakami DDoS. Po stronie klienta pojawiają się wtedy komunikaty tego rodzaju:

Internal Exception: io.netty.handler.timeout.ReadTimeoutException
Timed out
Connection reset

Po czym poznasz, że problem naprawdę zniknął

Poprawka liczy się dopiero wtedy, gdy wytrzyma dokładnie takie obciążenie, przy jakim problem wystąpił. W nocy przy dwóch graczach nawet zepsuty serwer chodzi gładko. Sprawdzaj w godzinach szczytu:

• spark tps pokazuje 20,0 w oknie 15-minutowym, a nie tylko w 5-sekundowym.
• 95. percentyl czasu ticka leży poniżej 40 ms, a maksimum poniżej 100 ms.
• 24 godziny logu bez ani jednego wiersza „Can't keep up!”.
• Świeży profil Spark nie pokazuje już żadnej pojedynczej pozycji powyżej 15 procent.
• spark gcmonitor nie zgłasza pauz dłuższych niż 200 ms.
• Gracze, którzy zgłaszali problem, potwierdzają poprawę w tym samym miejscu i przy tej samej rozgrywce.

Zapisuj wartości sprzed zmiany i po niej, najlepiej z datą oraz z opisem tego, co dokładnie zmieniłeś. Przy kolejnym załamaniu za trzy miesiące taka lista będzie warta więcej niż każdy poradnik, bo pokazuje, co już raz zadziałało na dokładnie twoim serwerze. Kto stawia serwer od nowa, znajdzie potrzebne podstawy we wpisach Instalacja serwera Minecraft na Debianie oraz Lista kontrolna dla nowego serwera root.