Lagi na serwerze Minecraft: najpierw znajdź przyczynę

Zanim zmienisz choć jedno ustawienie, ustal, który z trzech rodzajów lagów masz: pętla ticków serwera, która nie nadąża, sieć między graczami a serwerem albo komputer gracza, który nie radzi sobie z rysowaniem gry. Uruchom /spark tps w godzinie największego ruchu. Jeśli czasy ticków utrzymują się poniżej 50 ms, serwer nadąża, a lagi, które czują gracze, biorą się skądinąd.

Większość „poradników optymalizacji” pomija ten krok i wręcza ci listę ustawień. Część z nich pomaga, kilka pogarsza grę, a żadne nie naprawi problemu, którego jeszcze nie znaleziono. Ten poradnik zaczyna się od diagnozy.

Trzy rodzaje lagów (tick serwera, sieć, klient)

Mała dygresja dla geeków o liczbach, bo wyjaśnia, czemu TPS kłamie. Serwer dąży do 20 ticków na sekundę, więc każdy tick ma budżet 50 ms. TPS nigdy nie przekroczy 20, co oznacza, że serwer, któremu na tick wystarczy 10 ms, i serwer, który potrzebuje 48 ms, pokazują oba 20,0 TPS. Pierwszy zniesie kilkukrotnie większe obciążenie, a drugi dzieli od lagów jedna farma z lejami. MSPT (milisekundy na tick) pokazuje ten zapas, więc patrz na MSPT, a nie na TPS.

Mierz, zanim cokolwiek zmienisz

1. Wybierz właściwą godzinę. Lagów, które pojawiają się w szczycie, nie zmierzysz o piątej rano. Cztery najruchliwsze godziny na wszystkich serwerach z naszej listy to od 14:00 UTC do 18:00 UTC w twojej strefie czasowej, a publiczna strona statystyk twojego wpisu pokazuje twoje własne najruchliwsze godziny.
2. Uruchom /spark tps. Pokazuje TPS z ostatnich 5 sekund do 15 minut oraz czasy ticków jako minimum, medianę, 95. percentyl i maksimum. Mediana wyraźnie poniżej 50 ms przy 95. percentylu powyżej tej wartości oznacza skoki, a nie stałe przeciążenie. /mspt z Papera daje wersję skróconą.
3. Uruchom /spark health. Dodaje użycie procesora, pamięci i dysku, więc od razu widać, czy samej maszynie czegoś nie brakuje.
4. Czytaj konsolę. Vanillowe ostrzeżenie Can't keep up! Is the server overloaded? Running 2034ms or 40 ticks behind (konsola serwera zawsze pisze po angielsku) oznacza, że serwer został w tyle i przeskoczył do przodu, żeby nadrobić. Jedno na dobę to szum. Jedno na minutę to problem.
5. Zapisz stan wyjściowy: godzinę, liczbę graczy online, medianę i 95. percentyl MSPT oraz to, gdzie byli gracze (nowy obszar, duża farma, wydarzenie). Po każdej zmianie będziesz do tego wracać.

Na serwerze bez sparka vanillowe /tick query (Java Edition od 1.20.3, poziom uprawnień 3) podaje średni czas ticka i jego percentyle.

Szczyt 16:00 UTC

0003060912151821

Godziny w UTC

Najwięcej graczy o 16:00 UTC, około 17 845, najmniej o 01:00 UTC. W najruchliwszej godzinie gra 2,6 razy więcej osób niż w najspokojniejszej.

Pomiar: 19 paź 2026, 22:55 UTCJak mierzymy

Jak czytać profil sparka

Gdy liczby mówią, że serwer jest wolny, profiler mówi dlaczego. Dokumentacja PaperMC proponuje:

/spark profiler start --timeout 600

To próbkuje każdy wątek przez dziesięć minut i daje link do raportu. Dwa warianty pomagają przy konkretnych problemach:

• /spark profiler start --only-ticks-over 100 zapisuje tylko ticki wolniejsze niż 100 ms, co oddziela krótkie skoki lagów od zwykłego tła.
• /spark tickmonitor --threshold-tick 100 wypisuje linijkę za każdym razem, gdy tick trwa dłużej niż 100 ms, więc możesz dopasować skoki do tego, co działo się w grze.

Profil musi się nagrywać, gdy lag trwa. Profil cichego serwera o 05:00 nic nie mówi o lagu o 18:00.

W przeglądarce profilu otwórz wątek serwera i idź w dół za największym procentem. Szukasz gałęzi, w której ucieka czas:

• Tickowanie bytów, często z AI mobów albo szukaniem ścieżek przez wieśniaków pod spodem, wskazuje na moby (następna sekcja).
• Block entities (byty blokowe), z lejami wysoko na liście, wskazują na łańcuchy lejów i systemy magazynowe.
• Praca na chunkach (generowanie, ładowanie, zapisywanie) wskazuje na graczy odkrywających nowy teren.
• Nazwa pluginu w drzewie wywołań albo wysoko w zestawieniu według pluginów wskazuje na ten plugin. Zanotuj, co robił (obsługę zdarzenia, zaplanowane zadanie, zapytanie do bazy), zanim go obwinisz, bo ten sam plugin może działać dobrze przy innym ustawieniu.

Spark zapisuje też odśmiecanie pamięci (garbage collection). Częste pauzy rzędu setek milisekund wskazują na brak pamięci, co /spark gc pokazuje w czasie. Zrób profil raz także wtedy, gdy serwer działa dobrze, żeby było wiadomo, jak wygląda norma w twojej konfiguracji.

Zwykli podejrzani (byty, generowanie chunków, redstone, pluginy, garbage collection)

Byty

Farmy mobów, hale handlu z wieśniakami, stosy wyrzuconych przedmiotów, systemy wagoników i dekoracje ze stojaków na zbroję: wszystko to tickuje. Na Paperze /paper entity list pokazuje tickujące byty według typu, a filtr, taki jak /paper entity list minecraft:villager, zawęża listę, żeby znaleźć, gdzie się gromadzą. /paper mobcaps pokazuje, jak bardzo zapełnione są limity mobów, a /paper chunkinfo ile chunków jest załadowanych i tickujących. Rozwiązania to limity, a nie zakazy: górny limit bytów na chunk, zasady farm, na które zgadzają się twoi gracze, i rozmowa z tym, kto zbudował halę na 400 wieśniaków.

Generowanie chunków

Wygenerowanie nowego chunka to jedna z najdroższych rzeczy, jakie robi serwer, a gracze z elytrami potrafią wymusić ich dziesiątki na minutę. Wygeneruj świat z wyprzedzeniem, jednorazowo, pluginem takim jak Chunky (/chunky radius 5000, potem /chunky start) w cichych godzinach i ustaw pasującą granicę świata komendą /worldborder set 10000. Granica przyjmuje średnicę, a promień w Chunky to jej połowa, więc te dwie liczby opisują ten sam kwadrat. Potem eksplorowanie tylko ładuje chunki z dysku, co jest znacznie tańsze.

Redstone i leje

Szybkie zegary redstone i długie łańcuchy lejów się sumują. Paper daje dwie dźwignie w config/paper-world-defaults.yml. misc.redstone-implementation: ALTERNATE_CURRENT podmienia implementację pyłu redstone na szybszą. hopper.disable-move-event: true obniża koszt lejów, ale psuje pluginy, które polegają na tym zdarzeniu, na przykład niektóre pluginy ochrony i filtrów do lejów, więc najpierw przetestuj. hopper.cooldown-when-full jest już domyślnie włączone.

Pluginy

Ciężki plugin pojawia się w profilu z nazwy. Typowe wzorce to scoreboardy, hologramy albo listy tab przebudowywane co tick, zapytania do bazy lub sieci wykonywane na głównym wątku, renderery map świata przerabiające duży świat i kontrole antycheata pod obciążeniem. Rozwiązanie to zwykle najpierw konfiguracja (interwały odświeżania, limity renderowania), potem aktualizacja, na końcu wymiana.

Garbage collection

Jeśli spark pokazuje długie albo częste pauzy odśmiecania, sprawdź najpierw pamięć: czy -Xmx nie jest za małe na świat i pluginy i czy -Xms ma tę samą wartość? Flagi zalecane przez PaperMC to rozsądne ustawienie domyślne. Więcej pamięci pomaga tylko wtedy, gdy problemem jest odśmiecanie, a na współdzielonym hoście przydzielenie całej pamięci pozbawia jej system operacyjny.

Poprawki, które działają

Gdy znasz przyczynę, oto zmiany, które zwykle się opłacają, mniej więcej w kolejności, w jakiej byśmy je próbowali:

Zmiana simulation-distance jest większa, niż wygląda. Wokół każdego gracza serwer tickuje mniej więcej kwadrat chunków, więc zejście z 10 na 6 zmniejsza go z około 21 na 21 chunków do 13 na 13, czyli z około 441 chunków do około 169, a gracze nadal widzą tak daleko, jak pozwala view-distance.

Część popularnych rad nie pomaga. Pluginy, które co kilka minut czyszczą wszystkie wyrzucone przedmioty, leczą objaw i denerwują graczy. Pluginy „optymalizacyjne”, które obiecują wyższy TPS, nie mówiąc, co zmieniają, warto sprofilować przed i po. A restart co dwie godziny ukrywa problemy zamiast je znajdować.

Lag sieci widziany z zewnątrz

Jeden szczegół zaskakuje wielu właścicieli. Ping statusu, którego używają listy serwerów, obsługują wątki sieciowe serwera, a nie pętla ticków, więc serwer może w grze strasznie lagować i mimo to odpowiadać naszemu pingerowi w kilka milisekund. Lagów ticków nie widzimy z zewnątrz, i właśnie po to istnieje spark. Za Velocity pinger rozmawia zawsze tylko z proxy.

Nasz pinger widzi za to sieć. Publiczna strona statystyk twojego wpisu (/server/your-server/stats) pokazuje trzy rzeczy warte przeczytania:

• Czas odpowiedzi, czyli ile serwer potrzebował, żeby odpowiedzieć naszemu pingerowi, z medianą, zwykłym zakresem i wykresem. Poziom wyznacza głównie odległość od naszego pingera w zachodniej Europie, więc serwer w Stanach Zjednoczonych nie pokaże tam 10 ms, chyba że odpowiada sieć ochronna z pobliskiego węzła brzegowego (edge). Patrz na kształt w czasie, a nie na wartość.
• Skoki powyżej zwykłego zakresu. Jeśli odpowiedzi znacznie wychodzą ponad zwykły zakres tylko w twoich ruchliwych godzinach, maszyna albo jej łącze są wtedy nasycone. Jeśli zakres jest szeroki o każdej porze, podejrzewaj trasę albo sieć hosta.
• Dziennik awarii. Krótkie przerwy to restarty albo crashe. Długie przerwy zasługują na spojrzenie na stronę statusu hosta i na twoje raporty crashy.

Od strony graczy poproś poszkodowanych o traceroute do twojego adresu (tracert w Windows, traceroute na macOS i Linuksie) oraz o ich region. Jeśli wszyscy w jednym kraju mają lagi, a nikt poza nimi, to wina trasy, a przeniesienie serwera albo dodanie sieci ochronnej z pobliskim węzłem brzegowym może pomóc bardziej niż jakiekolwiek ustawienie. Gracze, którzy w ogóle nie mogą się połączyć, mają inne problemy, które omawia nasz poradnik o błędach połączenia.

Kiedy restartować, a kiedy nie

Restarty nie są darmowe. Wszyscy online dostają kicka, a gracz, którego wyrzuciło w środku walki w niedzielny wieczór, to zapamięta. Nasze dane o awariach pokazują, jak właściciele naprawdę je planują.

W 30 dniach do 16 października 2026 roku 90 wpisów na naszej liście było dostępnych do gry przez co najmniej 90% czasu. 58 z nich miało co najmniej jedną awarię, za którą uznajemy trzy lub więcej pingów z rzędu bez odpowiedzi świadczącej o dostępności do gry, i razem było ich 515. Mierząc od pierwszego nieudanego pingu do ostatniego, połowa awarii skończyła się w mniej niż pięć minut, a najdłuższa dziesiąta część trwała ponad dwie godziny. 375 z 515 (73%) trwało 15 minut lub krócej, czyli tyle, ile restart albo crash z ponownym uruchomieniem.

Kiedy zaczynały się te krótkie awarie? Jedna godzina się wyróżnia: 04:00 UTC, z 39 z 375, czyli kształt zaplanowanych nocnych restartów. Poza tą godziną rozkładają się dość równomiernie w ciągu doby. 64 z 375 (17%) zaczęło się między 14:00 a 18:00 UTC, w czterech najruchliwszych godzinach na naszej liście, co jest mniej więcej udziałem, jakiego można się spodziewać, gdyby godziny restartów wybierano losowo.

19%Krótkie awarie, które zaczęły się w czterech najruchliwszych godzinach listy, ostatnie 30 dni

Pomiar: 19 paź 2026, 21:52 UTCJak mierzymy

Na żywo, z ostatnich 30 dni: 472 awarii na 83 wpisach dostępnych do gry przez 90% czasu lub więcej, mediana 5 min minut, 70% z nich trwało 15 minut lub krócej. Najczęstsza godzina rozpoczęcia krótkich awarii to 04:00 UTC w twojej strefie czasowej, a najcichsza godzina całej listy to 01:00 UTC.

Co z tego wynika:

1. Restartuj w swojej własnej cichej godzinie, a nie o okrągłej godzinie. Pokazuje ją mapa cieplna na stronie statystyk, a raport o tym, kiedy serwery mają największy ruch, pokazuje, jak różni się to w regionach. Jeśli twoi gracze mieszkają w różnych strefach czasowych, wybierz najniższy punkt swojej krzywej, a nie północ.
2. Ogłoś go odliczaniem na czacie i niech będzie krótki.
3. Restartuj z powodu. Aktualizacje, wyciek pamięci, który śledzisz, zmiana konfiguracji, która tego wymaga. Codzienny restart, który niczego nie naprawia, i tak kosztuje codziennego kicka.
4. Znajdź wyciek zamiast go ukrywać. Jeśli pamięć rośnie aż do restartu, /spark heapsummary pokazuje, co ją zapełnia.

Restarty nie naprawiają lagów ticków. Farma, która kosztuje 30 ms na tick, kosztuje 30 ms na tick także pięć minut po restarcie. Nasz raport o uptime zawiera pełne liczby awarii z całej listy.

Kiedy ulepszyć sprzęt

Ulepszaj, gdy mówi to profil. Oznaki:

• MSPT w szczycie utrzymuje się powyżej około 40 ms po rozprawieniu się z podejrzanymi z listy wyżej.
• Profil pokazuje czas rozłożony na zwykłą pracę vanilli (byty, chunki, aktualizacje bloków), bez jednego pozostałego winowajcy.
• Na VPS top pokazuje rosnące w ruchliwych godzinach CPU steal (wartość st), co oznacza, że sąsiedzi używają rdzeni, za które ty płacisz.

Wtedy kupuj najpierw szybkość pojedynczego rdzenia, bo pętla ticków działa na jednym rdzeniu. Więcej RAM-u naprawia tylko problemy z pamięcią. Dalej odpowiedzią jest podział obciążenia: kilka serwerów za proxy Velocity albo Folia dla bardzo dużego świata, oba opisane w naszym poradniku o oprogramowaniu serwerów. Wybór hostingu zawiera pytania, które warto zadać, zanim zapłacisz za nową maszynę.