Diagnostyka lagu serwera Minecraft

Rodzaje lagu

Zanim zaczniemy diagnostykę, ważne jest rozróżnienie typów lagu. Każdy typ ma inne przyczyny i inne rozwiązania.

Ten poradnik skupia się na lagu serwerowym - to jedyny typ, który administrator serwera może zdiagnozować i naprawić. Lag sieciowy i klienta zależy od gracza. Więcej o optymalizacji serwera znajdziesz w osobnym poradniku.

TPS i MSPT - metryki wydajności

Dwie kluczowe metryki wydajności serwera Minecraft:

TPS (Ticks Per Second)

TPS to liczba tickow przetwarzanych przez serwer na sekunde. Idealny TPS wynosi 20.0 - co oznacza, ze serwer przetwarza 20 cykli logiki gry na sekundę (jeden tick co 50 milisekund).

MSPT (Milliseconds Per Tick)

MSPT to czas (w milisekundach) potrzebny na przetworzenie jednego ticku. To dokladniejsza metryka niż TPS:

• MSPT < 50 ms - TPS = 20.0, serwer ma zapas czasu
• MSPT = 50 ms - TPS = 20.0, ale na granicy - brak marginesu
• MSPT > 50 ms - TPS spada poniżej 20, serwer nie nadąża

MSPT jest ważniejszy niż TPS. Serwer może mieć TPS 20.0 z MSPT 48 ms - pozornie wszystko OK, ale jeden dodatkowy gracz lub ciezzki plugin może przepelnic bufor i spowodować spadek TPS. Monitoruj MSPT, nie tylko TPS.

Jak sprawdzić TPS i MSPT

/tps                    # podstawowy TPS (Spigot/Paper)
/spark tps              # dokładny TPS + MSPT + CPU (Spark)
/spark tickmonitor      # alerty gdy tick trwa dłużej niż 50ms

Spark Profiler

Spark to najważniejsze narzędzie do diagnostyki wydajności serwera Minecraft. Jest wbudowany w nowsze wersje Paper lub dostępny jako plugin. Stworzony przez autora LuckPerms, Spark oferuje:

• Profilowanie CPU - które funkcje/pluginy zużywają najwięcej czasu procesora
• Monitoring TPS/MSPT - dokładne pomiary w czasie rzeczywistym
• Analiza pamięci - zrzuty pamięci (heap dump) do znajdowania wycieków
• Tick monitor - powiadomienia o długich tickach
• Interaktywne raporty - wizualizacja w przeglądarce z drzewkiem wywołań

Instalacja Spark

Na Paper 1.21+ Spark jest już wbudowany. Na starszych wersjach lub Spigot:

# Pobierz z https://spark.lucko.me/download
# Umieść w plugins/
# Zrestartuj serwer

Profilowanie CPU - krok po kroku

1. Uruchom profiler: /spark profiler start
2. Graj normalnie przez 5-10 minut (odtwórz typowe obciążenie serwera)
3. Zatrzymaj profiler: /spark profiler stop
4. Otwórz raport - Spark wygeneruje link do interaktywnego raportu w przeglądarce
5. Analizuj wyniki - szukaj najgrubszych gałęzi w drzewku wywołań

Komendy Spark

Czytanie raportów Spark

Raport Spark wyświetla drzewko wywołań (call tree) - hierarchie funkcji z procentem czasu CPU, jaki każda z nich zuzyla. Oto jak go czytać:

Co szukać w drzewku

1. Najgrubsze galezei - funkcje zuzywajace najwięcej % czasu to główni winowajcy
2. Nazwy pluginów - szukaj nazw swoich pluginów w drzewku. Jeśli plugin zajmuje 40% czasu ticku - to problem
3. Entity ticking - jeśli entityTick lub tickEntities dominuje, masz za dużo mobów
4. Chunk loading/generation - jeśli chunkLoad lub chunkGenerate dominuje, potrzebujesz pre-generowania
5. Scheduler - jeśli BukkitScheduler jest wysoko, ktorysi plugin uruchamia cieżki kod co tick

Typowe wyniki i ich interpretacja

Spark generuje również raport w formacie umożliwiającym udostępnienie na Discordzie lub forum - jeśli potrzebujesz pomocy, udostępnij link do raportu na społeczności PaperMC Discord.

Paper Timings

Timings to starszy system profilowania wbudowany w Paper. Jest mniej szczegółowy niż Spark, ale nadal przydatny:

/timings on          # włącz zbieranie danych
# Poczekaj 5-10 minut typowej gry
/timings report      # wygeneruj raport (link do strony z wynikami)

Raport Timings wyświetla tabele z czasem spedzonym na poszczególnych operacjach. Szukaj wpisów z wysokim "Total" i "Per Tick" - to główne źródła lagu.

W nowszych wersjach Paper (1.21+) Spark jest rekomendowany zamiast Timings. Timings mogą być nawet wyłaczone domyslnie.

Najczęstsze przyczyny lagow

1. Za dużo entity (mobów, dropped itemow)

Najczęstsza przyczyna spadku TPS. Każdy mob wymaga obliczeń AI, pathfindingu i kolizji. 1000 mobów potrafi zaatakować TPS nawet na mocnym serwerze.

Diagnostyka: /spark profiler - szukaj entityTick w drzewku.

Rozwiazanie: Zmniejsz limity w bukkit.yml, ogranicz farmy mobów, zmniejsz despawn range w paper-world-defaults.yml.

2. Generowanie nowych chunkow

Gdy gracz eksploruje nowe tereny, serwer musi wygenerować chunki od zera - teren, jaskinie, struktury, oświetlenie. To niezwykle obciazajace.

Diagnostyka: Lagi występują gdy gracze eksplorują, nie gdy siedzą w bazie.

Rozwiazanie: Pre-generuj chunki pluginem Chunky i ustaw world border. Więcej w poradniku optymalizacji.

3. Ciężkie pluginy

Źle napisane pluginy mogą wykonywać operacje na głównym wątku serwera (synchroniczne zapytania SQL, obciążające schedulery).

Diagnostyka: Spark profiler pokaże nazwę pluginu w drzewku z wysokim % czasu.

Rozwiazanie: Zaktualizuj, wymień na lżejsza alternatywę lub zoptymalizuj konfiguracje.

4. Redstone lag machines

Skomplikowane obwody redstone (szczególnie zegary i flying machines) mogą znacznie obciążyć serwer.

Diagnostyka: /spark profiler - szukaj RedstoneWire lub pistonBase.

Rozwiazanie: Włącz optymalizacje redstone w Paper, ogranicz obwody pluginem RedstoneLimiter.

5. Autosave i zapisy na dysk

Okresowy zapis świata na dysk może powodować spiki lagow, szczególnie na serwerach z dużymi światami i wolnym dyskiem (HDD).

Diagnostyka: Spiki co kilka minut, widoczne w /spark tickmonitor.

Rozwiazanie: Zmniejsz max-auto-save-chunks-per-tick w Paper, użyj dysku SSD/NVMe.

6. Za mało RAM

Gdy serwer używa więcej pamięci niż przydzielono, Garbage Collector pracuje intensywnie, powodując spiki lagow.

Diagnostyka: /spark gc pokazuje częstotliwość i czas GC. Częste, długie pauzy GC = za mało RAM.

Rozwiazanie: Zwiększ pamięć w parametrach JVM (-Xmx). Więcej poniżej.

Diagnostyka entities

Entity (moby, dropped itemy, stojaki na zbroje, ramki na itemy) to najczęstsza przyczyna lagu serwerowego. Oto jak je zdiagnozowac:

/spark profiler start - only-ticks-over 100
# Poczekaj na kilka lagujacych tickow
/spark profiler stop

Opcja --only-ticks-over 100 profiluje tylko ticki trwające dłużej niż 100 ms - pozwala to uchwycic dokładnie co powoduje spiki.

Przydatne komendy

Diagnostyka chunkow

Chunki to drugaie najczęstsza przyczyna lagow. Problemy z chunkami objawiaja się szczególnie gdy gracze eksplorują nowe tereny.

Sprawdzenie załadowanych chunkow

/spark health          # ogólne informacje o chunach
/paper world info      # statystyki per świat (Paper)

Jeśli liczba załadowanych chunkow jest bardzo wysoka (ponad 5000), zmniejsz view-distance i simulation-distance w server.properties.

RAM i Garbage Collection

Java używa Garbage Collectora (GC) do automatycznego zwalniania nieuzywanej pamieci. GC może powodować pauzy - krótkie okresy, gdy serwer zamraża się na czas czyszczenia pamieci.

Diagnostyka GC

/spark gc              # statystyki GC
/spark health          # zużycie pamięci

Jeśli GC wykonuje się częściej niż co minute lub pauzy trwają dłużej niż 100 ms - masz problem z pamiecia.

Optymalne flagi JVM

Użyj flag Aikar - zoptymalizowanych specjalnie dla serwerów Minecraft:

java -Xms4G -Xmx4G   -XX:+UseG1GC   -XX:+ParallelRefProcEnabled   -XX:MaxGCPauseMillis=200   -XX:+UnlockExperimentalVMOptions   -XX:+DisableExplicitGC   -XX:+AlwaysPreTouch   -XX:G1NewSizePercent=30   -XX:G1MaxNewSizePercent=40   -XX:G1HeapRegionSize=8M   -XX:G1ReservePercent=20   -XX:G1HeapWastePercent=5   -XX:G1MixedGCCountTarget=4   -XX:InitiatingHeapOccupancyPercent=15   -XX:G1MixedGCLiveThresholdPercent=90   -XX:G1RSetUpdatingPauseTimePercent=5   -XX:SurvivorRatio=32   -XX:+PerfDisableSharedMem   -XX:MaxTenuringThreshold=1   -jar paper.jar - nogui

Kluczowe: -Xms i -Xmx powinny być takie same - zapobiega to dynamicznej zmianie rozmiaru sterty, co poprawia stabilność GC. Nie przydzielaj więcej niż 10-12 GB - zbyt dużo RAM prowadzi do długich pauz GC.

Ile RAM na ilu graczy?

Pamiętaj, ze RAM to nie jedyny czynnik. Procesor jednowątkowy (Minecraft głównie używa jednego rdzenia) i dysk SSD sa równie ważne.