Diagnoza lagów zaczyna się od uchwycenia problemu, a nie od losowej zmiany kilkunastu ustawień. PaperMC wskazuje spark jako preferowany profiler Paper i podkreśla, że pomiar ma sens wtedy, gdy spadki wydajności rzeczywiście trwają.
Najważniejsze konkrety
- Kiedy mierzyć
- Profiler musi działać podczas laga; raport z pustego i płynnego serwera nie pokaże przyczyny zdarzenia.
- Komenda
- Na Paper 1.21+ użyj /spark profiler start --timeout 600, aby zebrać dziesięć minut obciążenia.
- Progi
- 20 TPS odpowiada budżetowi 50 ms na tick; analizuj MSPT, procent czasu i szerokość gałęzi stosu.
- Kontekst
- Do linku dołącz godzinę, liczbę graczy, opis objawu, latest.log i kroki potrzebne do jego odtworzenia.
1. Opisz objaw, zanim zmienisz konfigurację
„Serwer laguje” może oznaczać różne rzeczy: opóźnione niszczenie bloków, cofanie ruchu, wolne otwieranie skrzyń, spadki FPS albo rozłączenia. Zapisz godzinę, świat, liczbę graczy, wykonywaną czynność i to, czy problem dotyczy wszystkich. Taki opis jest ważniejszy niż przypadkowe ustawienie z gotowej paczki optymalizacyjnej.
Oddziel problem sieci od problemu serwera. Wysoki ping może opóźniać komunikację z Twoim urządzeniem, a przeciążenie ticka dotyczy wykonywania logiki świata. Jeśli widzisz oba objawy, zmierz je osobno i nie przypisuj winy pluginowi bez raportu.
2. Użyj TPS i MSPT jako sygnału, nie wyroku
W Paper celem pętli gry jest 20 TPS. MSPT mówi, ile czasu zajmuje wykonanie ticka; przy 20 TPS jeden tick ma budżet około 50 ms. Średnia może wyglądać dobrze, gdy krótkie skoki znikają w pomiarze, dlatego zbieraj dane podczas realnego problemu.
PaperMC opisuje /tps i /mspt, ale wskazuje, że do profilowania należy korzystać z /spark. Nie zmieniaj jednocześnie view-distance, limitów mobów, pluginów i ustawień JVM - po takiej zmianie nie będziesz wiedzieć, co faktycznie pomogło.
3. Uruchom spark, gdy lag występuje
W Paper 1.21 i nowszych spark jest dołączony do serwera. Na starszym środowisku sprawdź, czy masz zaufany plugin spark. Uruchom profilowanie z konsoli albo jako administrator:
/spark profiler start --timeout 600
Dokumentacja PaperMC podaje tę komendę (otwiera w nowej karcie) jako podstawowy start dziesięciominutowego pomiaru. Jeśli problem trwa tylko chwilę, rozpocznij profilowanie przed odtworzeniem sytuacji. Gdy lag pojawia się raz dziennie, nie udawaj, że raport z pustej nocy opisuje przyczynę.
4. Czytaj raport w kontekście
Po zakończeniu spark zwróci adres raportu. Sprawdź, które ścieżki, pluginy lub zadania zajmowały czas podczas ticków, a następnie porównaj je z godziną i czynnością opisaną w zgłoszeniu. Wysoka pozycja w jednym fragmencie raportu nie jest jeszcze dowodem winy - plugin może być tylko miejscem, w którym ujawnia się problem z innym systemem.
Jeśli problem dotyczy generowania świata, sprawdź, czy gracze odkrywają dużo nowych chunków. Jeśli pojawia się przy farmie, evencie albo wielu encjach, zanotuj dokładne miejsce i warunki. Raport ma odpowiedzieć na pytanie „co wykonywało się w trakcie problemu?”, a nie tylko dostarczyć efektowny link.
Po zmianie wykonaj drugi profil w podobnych warunkach i porównaj raporty. Jeżeli pierwszy pomiar był w piątek przy 80 graczach, nie wyciągaj wniosku z drugiego wykonanego w pustym lobby. Porównywalny test jest ważniejszy niż pozornie niższa pojedyncza wartość.
5. Połącz profiler z logami
Otwórz logs/latest.log i poszukaj błędów, ostrzeżeń, powtarzających się wyjątków oraz komunikatów o przeładowaniu pluginu. Zestaw timestampy z raportu spark z godziną zgłoszenia. Nagły crash, spam błędów i długie ticki mogą mieć wspólną przyczynę, ale rozwiązuje się je inną procedurą.
Nie używaj komendy reload jako uniwersalnej metody naprawy. Po zmianie konfiguracji pluginu wykonaj kontrolowany restart zgodnie z instrukcją autora i zachowaj backup. Najpierw zbierz dowód, potem zmień jedną rzecz, a na koniec wykonaj ten sam test ponownie.
6. Przekaż pomocny raport
Do zgłoszenia dołącz adres raportu spark, wersję Minecrafta i Paper, listę pluginów, godzinę problemu, liczbę graczy, świat oraz kroki odtworzenia. Nie publikuj haseł, tokenów, adresów RCON ani prywatnych danych z konfiguracji. Jeśli raport pokazuje dane wrażliwe, udostępnij go tylko zaufanej osobie.
PaperMC kieruje raporty spark do kanału pomocy Paper (otwiera w nowej karcie) i przypomina, że profilowanie jest skuteczne, gdy problem aktywnie występuje. To dobry standard także przy kontakcie z autorem pluginu.
Od objawu do poprawki
- zapisz objaw, czas, świat i liczbę graczy;
- oddziel ping, FPS i opóźnienie ticków;
- uruchom spark przed lub w trakcie problemu;
- porównaj raport z logiem i warunkami odtworzenia;
- zmień jedną rzecz po wykonaniu backupu;
- powtórz ten sam test i zachowaj wynik;
- do pomocy wyślij raport bez sekretów i danych prywatnych.
Jeżeli oceniasz serwer przed dołączeniem, przeczytaj też poradnik o różnicy między pingiem i TPS, a następnie przetestuj projekt z listy serwerów Java w porze, w której chcesz grać.
Plan działania krok po kroku
- 1
Odtwórz problem i zanotuj dokładny czas, liczbę graczy, świat oraz wykonywaną czynność.
- 2
Uruchom profiler na 600 sekund w trakcie objawu; nie przeprowadzaj w tym samym czasie niezwiązanych restartów ani zmian.
- 3
W raporcie przejdź od głównego wątku do najszerszych gałęzi i oddziel pracę pluginów, encji, chunków oraz garbage collectora.
- 4
Połącz wynik z logiem, wprowadź jedną zmianę i zbierz drugi raport w porównywalnych warunkach.
