Znamy ten scenariusz z setek zgłoszeń: gracz dokłada serwerowi 8, 16, czasem 32 GB RAM, restartuje, wraca na świat i... dalej tnie. Mobki teleportują się w miejscu, bloki stawiają się z opóźnieniem, zegar w grze zwalnia. Pierwszy odruch jest zawsze ten sam, czyli "za mało pamięci". A prawda jest taka, że w większości przypadków RAM nie ma z tym nic wspólnego. Serwer Minecraft laguje z zupełnie innych powodów, a żeby je znaleźć, trzeba przestać patrzeć na pasek pamięci i zacząć patrzeć na dwie liczby: TPS i MSPT.
W tym wpisie pokażemy, co naprawdę odpowiada za płynność, jak zmierzyć źródło problemu i co z nim zrobić. To trzeci tekst z naszej serii o hostingu Minecraft i celowo wchodzi głębiej niż poradnik "kup więcej GB".
TPS i MSPT, czyli puls serwera
Serwer Minecraft działa w pętli zwanej tickiem. W każdym ticku silnik przelicza ruch mobów, redstone, wodę, wzrost roślin, AI, fizykę przedmiotów i setki innych rzeczy. Docelowo serwer wykonuje 20 ticków na sekundę, stąd TPS (ticks per second) ma wynosić właśnie 20. To sufit, nie da się przyspieszyć gry powyżej tej wartości, bo cała mechanika jest zaprojektowana wokół tego rytmu.
Skoro tick ma się powtarzać 20 razy na sekundę, to na pojedynczy tick przypada 50 milisekund. I tu wchodzi druga liczba, ważniejsza w diagnostyce: MSPT, czyli milliseconds per tick, to czas, jakiego serwer faktycznie potrzebuje na policzenie jednego ticku. Dopóki MSPT mieści się poniżej 50 ms, serwer zdąża i utrzymuje pełne 20 TPS. W momencie, gdy obliczenia zaczynają trwać dłużej niż 50 ms, serwer nie wyrabia w czasie, tiki się rozjeżdżają, a TPS spada.
Prosta zależność, którą warto zapamiętać:
- MSPT poniżej 50 ms to zdrowy serwer, TPS równe 20.
- MSPT w okolicach 45 do 50 ms to ostrzeżenie, jesteś na granicy.
- MSPT powyżej 50 ms to realne lagi, TPS leci w dół.
Co istotne, TPS może pokazywać równe 20, a serwer i tak zacina się skokowo. Dlatego my w pierwszej kolejności patrzymy na MSPT, bo to on pokazuje, ile naprawdę kosztuje pojedynczy tick i czy zdarzają się pojedyncze, długie skoki obliczeń, które gracz odczuwa jako mikroprzycięcia.
Dlaczego RAM rzadko jest przyczyną lagów
RAM w Minecraft to pojemność, nie szybkość. Pamięć przechowuje załadowane chunki, dane encji, struktury świata i obiekty pluginów. Jeśli tej pojemności zabraknie, serwer faktycznie zaczyna cierpieć, ale objawia się to inaczej niż klasyczne lagi. Przy realnym niedoborze RAM widać długie zawieszenia co kilkadziesiąt sekund (to garbage collector sprzątający pamięć) oraz wpisy o OutOfMemory w logach. To są konkretne, rozpoznawalne symptomy.
Natomiast typowe "wszystko chodzi wolno, mobki się ślizgają" to prawie nigdy nie jest sprawa pamięci. Dosypanie kolejnych gigabajtów do serwera, który ma za wolny tick, nie zmieni nic, bo wąskim gardłem jest procesor, a nie miejsce w pamięci. Co więcej, przesadne przydzielenie RAM potrafi zaszkodzić: im większa sterta, tym dłużej trwa jej czyszczenie, a długie pauzy GC to znów skoki MSPT.
Dla większości serwerów rozsądne widełki to 4 do 6 GB dla małej grupy z lekkimi pluginami i 8 do 10 GB dla średniego serwera survival lub prostego modpacku. Dopiero ciężkie modpacki potrafią uzasadnić więcej. Jak dobrać tę wartość świadomie, rozpisaliśmy w osobnym tekście ile RAM na serwer Minecraft. Warto też dorzucić tu poprawnie skonfigurowane flagi GC (popularne Aikar's flags), które dostrajają garbage collector G1 tak, by pauzy były krótkie i przewidywalne, zamiast jednej długiej blokady.
Single-thread CPU, czyli prawdziwe wąskie gardło
Tu dochodzimy do sedna. Główna pętla serwera Minecraft jest jednowątkowa. Cała logika świata, czyli ten tick, który ma się zmieścić w 50 ms, liczy się na praktycznie jednym rdzeniu procesora. Możesz mieć serwer z 32 rdzeniami i to nie pomoże głównej pętli, bo ona i tak korzysta zasadniczo z jednego.
Dlatego w hostingu Minecraft liczy się nie liczba rdzeni, ale wydajność pojedynczego rdzenia, czyli to, ile pracy procesor wykona w jednym wątku na sekundę. Nowoczesny, szybki rdzeń policzy ciężki tick w 30 ms, a stary, oszczędny serwer z dużą liczbą wolnych rdzeni utknie na 70 ms przy tym samym obciążeniu. To jeden z głównych powodów, dla których u nas stawiamy na procesory o wysokiej wydajności jednowątkowej, a nie na maszyny "z największą liczbą rdzeni za złotówkę".
Nowsze wersje Minecraft i serwery oparte na Paperze odciążają tę pętlę, przerzucając część zadań (sieć, generowanie chunków, niektóre obliczenia) na dodatkowe wątki. To pomaga, ale serce gry nadal bije w jednym wątku. Jeśli ten tick jest przeciążony, żadna ilość rdzeni ani RAM tego nie odwróci. Decyzja procesor kontra reszta zasobów to jeden z tematów, który poruszamy też przy okazji wyboru między hostingiem gry a VPS.
Co zżera tick: pluginy, redstone, mob farmy, chunk loadery
Skoro problem siedzi w czasie ticku, zobaczmy, co go najczęściej rozdmuchuje.
Ciężkie i źle napisane pluginy
Pojedynczy plugin potrafi położyć serwer bardziej niż dwudziestu graczy. Najgorsze są te, które w każdym ticku przeszukują cały świat, skanują encje, zapisują dane synchronicznie albo robią ciężkie operacje na bazie danych w głównym wątku. Plugin do ochrony terenu sprawdzający uprawnienia przy każdym postawionym bloku, źle skonfigurowany system ekonomii, plugin liczący statystyki na żywo: każdy z nich dolicza milisekundy do twojego budżetu 50 ms.
Redstone i kontraptiony
Złożone maszyny redstone, zwłaszcza zegary i pętle, generują ogromną liczbę aktualizacji bloków w każdym ticku. Jeden gracz budujący wydajną farmę z szybkim zegarem potrafi sam podnieść MSPT o kilkanaście milisekund. Mnożąc to przez kilku takich graczy, łatwo zjeść cały budżet.
Mob farmy i nadmiar encji
Każda encja (mob, przedmiot na ziemi, wagonik, rama) kosztuje czas obliczeń AI i fizyki. Wielkie farmy mobów, hordy zwierząt w zagrodach, tysiące porzuconych itemów leżących na ziemi: to klasyczne źródło spadków TPS. Czasem wystarczy posprzątać świat i ustawić limity, by serwer odżył.
Chunk loadery i wymuszone ładowanie
Mechanizmy trzymające chunki załadowane na siłę (przez plugin, hopper minecart albo wymuszone ładowanie) sprawiają, że serwer ciągle przelicza obszary, na których nikogo nie ma. Im więcej takich aktywnych chunków, tym więcej pracy w każdym ticku, nawet gdy serwer wydaje się pusty.
Narzędzia diagnostyczne: spark i timings
Zgadywanie nie ma sensu, bo profilery powiedzą dokładnie, co zjada tick.
spark to dziś nasze podstawowe narzędzie. Komenda /spark profiler uruchamia profilowanie, a po kilku minutach dostajesz link do raportu, który rozbija czas ticku na konkretne pluginy, metody i mechaniki. Widać czarno na białym, że to plugin X albo encje w danym miejscu zżerają najwięcej. spark pokazuje też wykres MSPT w czasie, dzięki czemu wyłapiesz pojedyncze skoki.
Timings (głównie na starszym Paperze i Spigocie) działa podobnie, generując webowy raport z podziałem czasu na zadania i pluginy. Na nowszych wersjach Paper przeszedł na spark, więc jeśli zaczynasz teraz, idź od razu w spark.
Schemat działania jest prosty: uruchom profiler na ruchliwym serwerze, zbieraj dane kilka minut przy realnym obciążeniu, otwórz raport i znajdź największego winowajcę. W praktyce w 80% przypadków odpowiedź wyskakuje na samej górze listy.
Paper, Purpur i ustawienia, które realnie pomagają
Jeśli wciąż stoisz na czystym Vanilli lub starym Spigocie, sama zmiana silnika potrafi dać największy skok wydajności bez dotykania sprzętu.
Paper to mocno zoptymalizowana wersja serwera, zgodna z pluginami Bukkit/Spigot, z dziesiątkami poprawek wydajności i bogatym plikiem konfiguracyjnym, w którym dostroisz zachowanie mobów, redstone i ładowania chunków. Purpur idzie krok dalej, bazuje na Paperze i dokłada jeszcze więcej opcji strojenia. Dla zdecydowanej większości serwerów survival i mini-gier Paper lub Purpur to dziś domyślny, rozsądny wybór.
Po stronie ustawień największą dźwignią są dwie wartości:
- view-distance decyduje, ile chunków wokół gracza jest wysyłanych i renderowanych. Zejście z 12 czy 16 na 8 albo 6 potrafi drastycznie odciążyć serwer.
- simulation-distance określa, w jakim promieniu chunki są aktywnie symulowane (mobki, rośliny, redstone). To ona realnie obciąża tick, więc obniżenie jej, na przykład do 4 do 6, często daje większy zysk niż samo view-distance.
W konfiguracji Paper warto też dostroić limity spawnu mobów i częstotliwość zapisu danych. To detale, ale składają się na różnicę między 18 a 20 TPS przy pełnym serwerze.
Pre-generacja świata, czyli koniec lagów przy eksploracji
Jeden z najczęstszych i najbardziej mylących objawów to lagi pojawiające się tylko wtedy, gdy gracze ruszają w nieznane rejony. Powód: generowanie nowych chunków jest kosztowne, a robione na bieżąco, gdy ktoś biegnie w teren, dokłada serwerowi pracy dokładnie w najgorszym momencie.
Rozwiązaniem jest pre-generacja świata. Pluginami w stylu Chunky generujesz z góry obszar mapy (na przykład promień kilku tysięcy bloków od spawnu), zanim gracze tam dotrą. Robi się to najlepiej przy pustym serwerze, bo proces sam w sobie obciąża maszynę. Potem, gdy gracze eksplorują, chunki są już gotowe i serwer ich nie generuje na żywo. Połączenie pre-generacji z sensownym promieniem world border to jeden z najskuteczniejszych sposobów na płynny survival.
Jak podejść do tego po kolei
Gdy ktoś zgłasza nam lagi mimo dużego RAM, idziemy zawsze tą samą drogą:
- Sprawdzamy TPS i MSPT, żeby wiedzieć, czy problem jest w samym ticku, czy gdzie indziej.
- Odpalamy spark i czytamy raport, zamiast zgadywać.
- Patrzymy na pluginy, encje, redstone i chunk loadery jako pierwszych podejrzanych.
- Upewniamy się, że serwer chodzi na Paper lub Purpur z rozsądnym view i simulation distance.
- Pre-generujemy świat i pilnujemy granic mapy.
- Dopiero na końcu, jeśli logi pokazują długie pauzy GC albo OutOfMemory, ruszamy RAM i flagi.
W tej kolejności RAM ląduje na samym dole, bo tam jest jego realne miejsce w diagnostyce lagów. Jeśli chcesz dobrać konfigurację serwera świadomie, od mocnego pojedynczego rdzenia po sensowną pamięć, możesz to złożyć w naszym konfiguratorze i zacząć od sprzętu, który nie wąsi się już na starcie. A jeśli przy okazji dobierasz pamięć i nie chcesz przepłacać ani głodzić serwera, pomoże osobny tekst o tym, ile RAM na serwer Minecraft faktycznie wziąć.
Zespół NobleNodes