Diagnostyka lagu serwera Minecraft

Rodzaje lagu

Zanim zaczniemy diagnostyke, ważne jest rozroznienie typow 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 zdiagnozowac i naprawić. Lag sieciowy i klienta zalezy 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 sekunde (jeden tick co 50 milisekund).

MSPT (Milliseconds Per Tick)

MSPT to czas (w milisekundach) potrzebny na przetworzenie jednego ticku. To dokladniejsza metryka niz 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 nadaza

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

Jak sprawdzić TPS i MSPT

/tps                    # podstawowy TPS (Spigot/Paper)
/spark tps              # dokladny TPS + MSPT + CPU (Spark)
/spark tickmonitor      # alerty gdy tick trwa dłużej niz 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 zuzywaja najwięcej czasu procesora
• Monitoring TPS/MSPT - dokladne pomiary w czasie rzeczywistym
• Analiza pamieci - zrzuty pamieci (heap dump) do znajdowania wyciekow
• Tick monitor - powiadomienia o dlugich tickach
• Interaktywne raporty - wizualizacja w przegladarce z drzewkiem wywolan

Instalacja Spark

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

# Pobierz z https://spark.lucko.me/download
# Umiesc 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 obciazenie serwera)
3. Zatrzymaj profiler: /spark profiler stop
4. Otworz raport - Spark wygeneruje link do interaktywnego raportu w przegladarce
5. Analizuj wyniki - szukaj najgrubszych galezi w drzewku wywolan

Komendy Spark

Czytanie raportow Spark

Raport Spark wyswietla drzewko wywolan (call tree) - hierarchie funkcji z procentem czasu CPU, jaki każda z nich zuzyla. Oto jak go czytać:

Co szukac w drzewku

1. Najgrubsze galezei - funkcje zuzywajace najwięcej % czasu to glowni winowajcy
2. Nazwy pluginow - szukaj nazw swoich pluginow 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 udostepnienie na Discordzie lub forum - jeśli potrzebujesz pomocy, udostepnij link do raportu na społeczności PaperMC Discord.

Paper Timings

Timings to starszy system profilowania wbudowany w Paper. Jest mniej szczegółowy niz 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 wyswietla tabele z czasem spedzonym na poszczegolnych operacjach. Szukaj wpisow 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.

Najczestsze przyczyny lagow

1. Za dużo entity (mobow, dropped itemow)

Najczestsza przyczyna spadku TPS. Każdy mob wymaga obliczen AI, pathfindingu i kolizji. 1000 mobow potrafi zaatakowac TPS nawet na mocnym serwerze.

Diagnostyka: /spark profiler - szukaj entityTick w drzewku.

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

2. Generowanie nowych chunkow

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

Diagnostyka: Lagi występują gdy gracze eksploruja, nie gdy siedza w bazie.

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

3. Ciezkie pluginy

Źle napisane pluginy mogą wykonywac operacje na głównym watku serwera (synchroniczne zapytania SQL, obciazajace schedulery).

Diagnostyka: Spark profiler pokaze nazwe pluginu w drzewku z wysokim % czasu.

Rozwiazanie: Zaktualizuj, wymien na lzejsza alternatywe lub zoptymalizuj konfiguracje.

4. Redstone lag machines

Skomplikowane obwody redstone (szczególnie zegary i flying machines) mogą znacznie obciazyc 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 powodowac spiki lagow, szczególnie na serwerach z duzymi światami i wolnym dyskiem (HDD).

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

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

6. Za malo RAM

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

Diagnostyka: /spark gc pokazuje częstotliwość i czas GC. Czeste, długie pauzy GC = za malo RAM.

Rozwiazanie: Zwieksz pamiec w parametrach JVM (-Xmx). Więcej poniżej.

Diagnostyka entities

Entity (moby, dropped itemy, stojaki na zbroje, ramki na itemy) to najczestsza 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 trwajace dłużej niz 100 ms - pozwala to uchwycic dokładnie co powoduje spiki.

Przydatne komendy

Diagnostyka chunkow

Chunki to drugaie najczestsza przyczyna lagow. Problemy z chunkami objawiaja się szczególnie gdy gracze eksploruja nowe tereny.

Sprawdzenie zaladowanych chunkow

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

Jeśli liczba zaladowanych 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 powodowac pauzy - krotkie okresy, gdy serwer zamraza się na czas czyszczenia pamieci.

Diagnostyka GC

/spark gc              # statystyki GC
/spark health          # zuzycie pamieci

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

Optymalne flagi JVM

Uzyj flag Aikar - zoptymalizowanych specjalnie dla serwerow 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 niz 10-12 GB - zbyt dużo RAM prowadzi do dlugich pauz GC.

Ile RAM na ilu graczy?

Pamietaj, ze RAM to nie jedyny czynnik. Procesor jednowatkowy (Minecraft głównie używa jednego rdzenia) i dysk SSD sa rownie ważne.