Jak sprawdzić TPS i MSPT serwera Minecraft? Poradnik diagnostyczny

TPS i MSPT to dwa podstawowe wskaźniki, które pomagają ocenić, czy serwer Minecraft Java działa płynnie. Dzięki nim możesz odróżnić problem z wydajnością serwera od opóźnienia sieciowego po stronie gracza. Samo wrażenie „lagów” nie wystarcza do diagnozy — najpierw sprawdź pomiary, a dopiero potem zmieniaj konfigurację.

Ten poradnik dotyczy przede wszystkim serwerów Paper i podobnych silników Bukkit. Jeżeli potrzebujesz stabilnej instancji do testów, pluginów i monitorowania wydajności, sprawdź hosting Minecraft Java Vorlantix oraz dostęp do konfiguracji w panelu klienta.

Czym jest TPS?

TPS, czyli ticks per second, określa liczbę cykli symulacji wykonywanych przez serwer w ciągu sekundy. Minecraft Java dąży do wartości 20 TPS. Przy takim wyniku świat działa zgodnie z założonym tempem: redstone, AI mobów, obrażenia i inne zdarzenia są przetwarzane bez opóźnień wynikających z przeciążenia głównego wątku.

Wynik 20 TPS nie oznacza, że każdy gracz ma dobry ping. Oznacza tylko, że serwer wykonuje swoje ticki w prawidłowym tempie. Jeżeli TPS spada, serwer zaczyna nadrabiać obliczenia, a gracze mogą zauważyć opóźnione komendy, zatrzymywanie mobów, cofanie bloków lub opóźnione obrażenia.

Paper pokazuje zwykle średnie TPS z kilku okresów, na przykład z ostatniej minuty, pięciu minut i piętnastu minut. Krótki spadek po uruchomieniu świata nie musi oznaczać stałego problemu. Znacznie ważniejszy jest powtarzalny spadek podczas konkretnej aktywności, takiej jak eksploracja mapy, działanie farmy lub wejście większej liczby graczy.

Czym jest MSPT?

MSPT oznacza milliseconds per tick, czyli liczbę milisekund potrzebnych do wykonania jednego ticka. To bardziej bezpośredni pomiar czasu pracy serwera niż sam TPS. Aby utrzymać 20 TPS, tick powinien zmieścić się w około 50 ms.

• MSPT poniżej 50 ms — serwer ma zapas i może utrzymywać 20 TPS.
• MSPT blisko 50 ms — serwer pracuje na granicy stabilności.
• MSPT powyżej 50 ms — tick trwa za długo, więc TPS może spadać.
• Wysokie chwilowe wartości — mogą oznaczać pojedynczy ciężki tick, na przykład generowanie chunków.

MSPT może być wysoki nawet wtedy, gdy średni TPS przez chwilę wygląda poprawnie. Dlatego warto obserwować średnią, minimum i maksimum oraz powtarzać pomiar w czasie występowania problemu.

Jak sprawdzić TPS w konsoli Paper?

Najprostszą metodą jest komenda Paper:

tps

W konsoli serwera wpisujesz ją bez ukośnika. W grze operator może użyć:

/tps

Odczytaj wartości dla kilku przedziałów czasu. Jeżeli wynik spada tylko w momencie wejścia na nowy teren, obserwuj serwer podczas eksploracji. Jeżeli spadek utrzymuje się przez cały czas, sprawdź pluginy, liczbę encji i konfigurację odległości symulacji.

Jak sprawdzić MSPT?

Do sprawdzenia czasu ticka użyj:

mspt

W grze komenda wygląda tak:

/mspt

Paper może wyświetlić średni, minimalny i maksymalny MSPT z kilku ostatnich okresów. Najbardziej przydatny jest pomiar wykonany w chwili, gdy gracze rzeczywiście zgłaszają lagi. Wynik z okresu, w którym serwer jest pusty, może nie pokazać problemu związanego z farmą, generowaniem świata albo konkretnym pluginem.

Diagnostyka za pomocą Spark

Współczesne wydania Paper mają wbudowany profiler Spark. Jest on przydatniejszy niż sam pojedynczy odczyt TPS, ponieważ pokazuje, na jakie zadania serwer przeznacza czas. Profilowanie uruchamiaj wtedy, gdy problem faktycznie występuje.

Przykładowa sesja profilowania trwająca dziesięć minut:

/spark profiler start --timeout 600

Po zakończeniu Spark zwróci adres raportu. W raporcie można szukać między innymi obciążających pluginów, generowania chunków, operacji encji i długich zadań wykonywanych w głównym wątku. Nie uruchamiaj profilera bez potrzeby przez wiele godzin — zbieraj dane w krótkim okresie, w którym da się odtworzyć problem.

Jeśli chcesz poznać pełną procedurę, przejdź do przygotowywanego poradnika Jak używać Spark do diagnozy lagów?. Warto także zapisać wyniki i porównać je z pomiarem po zmianie konfiguracji.

Jak interpretować wyniki?

20 TPS i niski MSPT

To zwykle oznacza, że główny cykl serwera działa prawidłowo. Jeśli gracze nadal odczuwają opóźnienia, sprawdź ping, utratę pakietów, trasę sieciową, obciążenie komputera klienta oraz działanie konkretnego pluginu. Nie ma powodu zmieniać ustawień Paper tylko dlatego, że jedna osoba widzi opóźnienie.

Niskie TPS i MSPT powyżej 50 ms

Serwer nie nadąża z wykonywaniem ticków. Przyczyną może być plugin, generowanie świata, zbyt duża liczba encji, redstone lub zbyt wysokie simulation-distance. Uruchom Spark w chwili problemu i sprawdź logi.

20 TPS, ale wysoki ping graczy

Wysoki ping nie musi mieć związku z TPS. Gracz może być daleko od serwera, korzystać z niestabilnego Wi-Fi albo mieć problem z trasą operatora internetowego. Sprawdź, czy problem dotyczy wszystkich osób, czy tylko jednego połączenia.

TPS wygląda dobrze, ale pojawiają się chwilowe przycięcia

Średnia może ukrywać krótkie skoki MSPT. Takie przycięcia często pojawiają się podczas zapisu świata, generowania chunków, dużych operacji WorldEdit albo wykonywania ciężkiego zadania przez plugin. Wykonaj profilowanie Spark z filtrem na dłuższe ticki, na przykład:

/spark profiler start --only-ticks-over 100 --timeout 300

Wartość 100 oznacza, że raport skupi się na tickach trwających dłużej niż 100 ms. Dobierz próg do problemu i zachowaj raport do porównania.

Serwer czy sieć — jak rozpoznać przyczynę?

W panelu klienta możesz dodatkowo sprawdzić zużycie CPU, RAM oraz obciążenie instancji. Otwórz panel Vorlantix i porównaj dane systemowe z wynikami komend wykonywanych w grze lub konsoli.

Najczęstsze błędy przy pomiarach

• Pomiar jest wykonywany, gdy serwer jest pusty, mimo że problem pojawia się przy kilku graczach.
• Właściciel zmienia wiele ustawień przed ponownym sprawdzeniem wyników.
• Wysoki ping jest mylony ze spadkiem TPS.
• Raport Spark jest tworzony po zakończeniu problemu.
• Wynik jednego krótkiego odczytu jest traktowany jako stała kondycja serwera.

Dobry pomiar powinien mieć kontekst: wersję Minecraft, silnik serwera, liczbę graczy, aktywność w świecie, czas wystąpienia problemu i wynik kilku komend. Dzięki temu łatwiej porównać sytuację przed oraz po optymalizacji.

Wyniki zapisuj przed każdą większą zmianą konfiguracji. Krótka notatka z datą, liczbą graczy i aktywnością na serwerze często pozwala szybko ustalić, czy poprawa była rzeczywista, czy tylko wynikała z chwilowo mniejszego obciążenia.

Podsumowanie

TPS pokazuje, czy serwer utrzymuje tempo symulacji, a MSPT informuje, ile czasu zajmuje wykonanie pojedynczego ticka. W Paper sprawdzisz je komendami /tps i /mspt, ale do znalezienia przyczyny problemu najlepiej użyć Spark. Niski TPS razem z wysokim MSPT wskazuje na przeciążenie serwera, natomiast prawidłowe wartości przy problemie jednego gracza sugerują opóźnienie sieciowe lub lokalne.