Lagi na serwerze Minecraft: przyczyny i jak je usunąć

Gracze narzekają na lagi. Bloki łamią się z opóźnieniem, moby się teleportują, itemy się nie podnoszą. Wchodzisz do konsoli, i niby wszystko ok - pamięć nie jest zapełniona, CPU nie na 100%. Ale lagi są. Co się dzieje?

Jeśli jesteś adminem serwera Minecraft i chcesz rozkminić, dlaczego zwalnia - ten artykuł jest dla ciebie. Bez lania wody, bez ogólników. Konkretne przyczyny, konkretne narzędzia, konkretne configi.

Czym jest TPS i dlaczego to główna metryka

TPS - Ticks Per Second. Serwer Minecraft działa w cyklu: w każdym ticku obsługuje wszystko, co dzieje się w świecie. Ruch mobów, wzrost roślin, aktualizację redstone'a, obsługę pakietów od graczy. Idealnie w ciągu sekundy zachodzi 20 ticków. Jeden tick = 50 milisekund.

• 20 TPS - wszystko idealnie, serwer się wyrabia
• 18-19 TPS - nieznaczne obniżenie, gracze raczej nie zauważą
• 15-17 TPS - już odczuwalne, moby ruszają się skokowo
• 10-14 TPS - poważne lagi, grać niekomfortowo
• Poniżej 10 TPS - serwer ledwo oddycha

Sprawdzić aktualny TPS można komendą /tps (Spigot/Paper) albo przez spark.

Ważne zrozumieć: TPS nie może być wyższy niż 20. Jeśli masz 20.0 TPS, to nie znaczy, że serwer bezczynnieje. To znaczy, że wyrabia się obsłużyć tick w 50 ms albo szybciej. Żeby zrozumieć realne obciążenie, trzeba patrzeć na MSPT - milliseconds per tick.

/spark tps
/spark health

MSPT 30 ms przy 20 TPS oznacza, że masz zapas 20 ms. MSPT 48 ms - też 20 TPS, ale jesteś na granicy. Jeszcze trochę obciążenia, i TPS zacznie spadać.

Spark: twoje główne narzędzie diagnostyki

Zapomnij o wbudowanym timings w Paperze. Jest przestarzały i daje dużo mniej informacji. Stawiaj spark - to profiler, który pokaże, co konkretnie żre zasoby.

Instalacja

Pobierz plik jar z spark.lucko.me i połóż do folderu plugins/. Przeładuj serwer.

Podstawowe użycie

/spark profiler start     -- zacząć zapis profilu

Poczekaj 2-5 minut, aż serwer popracuje w normalnym trybie. Potem:

/spark profiler stop      -- zatrzymać i dostać link

Spark poda link do raportu. Otwórz w przeglądarce. Zobaczysz drzewo wywołań - jakie funkcje ile czasu zajmują. Szukaj najbardziej "ciężkich" gałęzi.

Na co zwracać uwagę

• Entity tick - obsługa encji. Jeśli tutaj więcej niż 30-40% czasu, masz zbyt dużo mobów albo słabo zoptymalizowany plugin, który wiesza logikę na Entity tick
• Chunk loading/generation - generacja i ładowanie chunków. Jeśli to miejsce numer jeden w profilu, generuj świat z góry
• Obsługiwacze pluginów - spark pokaże konkretne pluginy i ich obsługiwacze eventów. Często jeden źle napisany plugin może zabić cały serwer
• Scheduled tasks - zadania według harmonogramu. Synchroniczne zadania blokują główny tick

Przyczyna 1: Zbyt dużo encji

To najczęstsza przyczyna lagów. Encje (entities) to moby, dropnięte itemy, strzały, ramki, wagoniki, stojaki na zbroje. Każda encja jest obsługiwana w każdym ticku.

1000 krów w jednej zagrodzie? Gratuluję, masz lag-maszynę.

Diagnostyka

/spark tickmonitor

Albo zobacz przez:

/minecraft:debug entities

Rozwiązanie

W paper-global.yml (Paper 1.19+) albo paper.yml (stare wersje):

# paper-world-defaults.yml
entities:
  spawning:
    monster-spawn-range: 6          # default 8
    creative-arrow-despawn-rate: 60
    non-player-arrow-despawn-rate: 60

W spigot.yml:

entity-activation-range:
  animals: 16          # default 32
  monsters: 24         # default 32
  raiders: 48
  misc: 8              # default 16
  water: 8             # default 16
  villagers: 16        # default 32
  flying-monsters: 32  # default 32
  tick-inactive-villagers: false
  wake-up-inactive:
    animals-max-per-tick: 4
    animals-every: 1200
    animals-for: 100
    monsters-max-per-tick: 8
    monsters-every: 400
    monsters-for: 100

Entity activation range określa, w jakiej odległości od gracza encje dostają pełny tick. Poza tym promieniem są tickowane rzadziej - oszczędność ogromna.

Drop itemów

Itemy leżące na ziemi - też encje. Skonfiguruj despawn:

# spigot.yml
item-despawn-rate: 3000   # default 6000 (5 minut), stawiamy 2.5 minuty

Postaw plugin ClearLagg albo napisz prosty skrypt, który czyści drop co 5 minut. Uprzedzaj graczy na 30 sekund.

Przyczyna 2: Ładowanie i generacja chunków

Kiedy gracz się przemieszcza, serwer musi ładować nowe chunki. Jeśli chunki jeszcze nie były wygenerowane - trzeba je stworzyć. Generacja chunków - jedna z najcięższych operacji.

Pregeneracja świata

Użyj Chunky do pregeneracji:

/chunky radius 5000
/chunky start

Zostaw na noc. Pregeneracja mapy 5000 bloków od spawnu zajmie kilka godzin, ale potem nowym graczom nie trzeba będzie czekać na generację.

view-distance i simulation-distance

To najpotężniejsze dźwignie optymalizacji. W server.properties:

view-distance=7
simulation-distance=4

view-distance - ile chunków wokół gracza jest wysyłanych do klienta. Default 10, ale dla większości serwerów 7-8 aż nadto wystarczy.

simulation-distance - ile chunków wokół gracza jest realnie tickowanych (moby się ruszają, redstone działa, rośliny rosną). To krytyczne ustawienie. Zmniejszenie z 10 do 4-5 radykalnie zmniejsza obciążenie.

Ważne: simulation-distance musi być mniejsze lub równe view-distance. Gracze będą widzieć chunki, ale w dalekich chunkach nic nie będzie się ruszało. Dla większości jest to akceptowalne.

Przyczyna 3: Redstone

Automatyczne farmy na redstone - ból każdego serwera. Jeden nieskończony generator taktowy może obniżyć TPS całemu serwerowi.

Limity w Paperze

# paper-global.yml
chunk-system:
  gen-parallelism: default

# paper-world-defaults.yml
redstone-implementation: ALTERNATE_CURRENT

ALTERNATE_CURRENT - alternatywna implementacja aktualizacji redstone'a, znacznie szybsza niż waniliowa. Niektóre bardzo skomplikowane schematy mogą się zepsuć, ale dla 99% użytku jest super.

Limit na tłoki i hoppery

# paper-world-defaults.yml
hopper:
  cooldown-when-full: true
  disable-move-event: false
  ignore-occluding-above: false

Hoppery - jeden z najdroższych bloków pod względem wydajności. cooldown-when-full: true znacznie zmniejsza obciążenie od pełnych hopperów.

Przyczyna 4: Pluginy

Źle napisane pluginy - druga co do częstotliwości przyczyna lagów po encjach. Oto typowe problemy:

• Synchroniczne zapytania do bazy danych. Plugin robi zapytanie SQL w głównym wątku, i póki czeka na odpowiedź, cały serwer stoi. To zabójca TPS. Stawiaj tylko pluginy od sprawdzonych deweloperów
• Ciężkie obsługiwacze eventów. Plugin na PlayerMoveEvent, który w każdym ticku sprawdza coś skomplikowanego dla każdego gracza
• Wycieki pamięci. Plugin tworzy obiekty, ale ich nie usuwa. Z czasem GC zaczyna panikować

Jak znaleźć problemowy plugin

Spark pokaże to bezpośrednio w profilu. Ale można prościej - wyłączaj pluginy po jednym (metodą podziału na pół) i patrz na TPS.

Jeśli podejrzewasz konkretny plugin:

/spark profiler start --only-ticks-over 50

To zapisze profil tylko tych ticków, które zajęły więcej niż 50 ms (czyli wywołały spadek TPS). W raporcie będzie widać, co konkretnie spowalnia.

Przyczyna 5: Garbage Collector (GC)

Java używa garbage collectora do zarządzania pamięcią. Kiedy GC się uruchamia, może na chwilę zatrzymać cały serwer. Jeśli masz wydzielone 16 GB RAM, a GC jest źle skonfigurowany, pauzy mogą być 200-500 ms. To 4-10 straconych ticków na raz.

Flagi Aikara

Aikar (deweloper Papera) zestawił zestaw flag JVM zoptymalizowanych pod Minecrafta. Używaj ich:

Dla serwerów z 12 GB RAM i mniej:

java -Xms10G -Xmx10G -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:G1MixedGCCountTarget=4 -XX:InitiatingHeapOccupancyPercent=15 \
  -XX:G1MixedGCLiveThresholdPercent=90 \
  -XX:G1RSetUpdatingPauseTimePercent=5 \
  -XX:SurvivorRatio=32 -XX:+PerfDisableSharedMem \
  -XX:MaxTenuringThreshold=1 \
  -jar server.jar --nogui

Kluczowe momenty:

• -Xms i -Xmx takie same - to ważne. Java nie będzie tracić czasu na zmianę rozmiaru stosu
• -XX:+UseG1GC - collector G1, optymalny dla Minecrafta
• -XX:MaxGCPauseMillis=200 - docelowa pauza GC nie większa niż 200 ms
• -XX:G1NewSizePercent=30 i G1MaxNewSizePercent=40 - Minecraft tworzy dużo krótkożyjących obiektów, dlatego Young Generation jest powiększony

Ile RAM wydzielać

Częsty błąd - wydzielać za dużo RAM. 32 GB dla serwera na 50 graczy - to przesada. Im większy stos, tym dłuższa pauza GC.

Orientacyjnie:

• Vanilla/Paper do 20 graczy: 4-6 GB
• Paper 20-50 graczy: 6-10 GB
• Paper 50-100 graczy z pluginami: 10-14 GB
• Forge z modami: zależy od modpacka, ale zaczynajcie od 8 GB

Paper i Purpur: co kręcić

Jeśli nadal jesteś na Spigocie - przesiadaj się na Papera. Jeśli na Paperze - zerknij na Purpura. Każdy z nich dodaje optymalizacje, których nie ma w wanili.

paper-global.yml

chunk-system:
  gen-parallelism: default
  io-threads: 4
  worker-threads: 4

async-chunks:
  threads: 4

paper-world-defaults.yml

entities:
  spawning:
    per-player-mob-spawns: true
    alt-item-despawn-rate:
      enabled: true
      items:
        cobblestone: 300
        netherrack: 300
        sand: 300
        gravel: 300
        dirt: 300
        short_grass: 300
        kelp: 300
        bamboo: 300

environment:
  treasure-maps:
    enabled: true
    find-already-discovered:
      loot-tables: true
      villager-trade: true
  optimize-explosions: true

tick-rates:
  mob-spawner: 2
  sensor:
    villager:
      secondarypoisensor: 80
  behavior:
    villager:
      validatenearbypoi: -1

per-player-mob-spawns: true - zamiast globalnego limitu mobów, limit liczony na gracza. Jeden gracz z gigantyczną farmą nie zabierze całego limitu mobów serwera.

alt-item-despawn-rate - śmieciowe bloki (kamień, ziemia) znikają szybciej. Gracze nie zauważą, a encji na serwerze będzie mniej.

optimize-explosions: true - zoptymalizowany algorytm wybuchów. Obowiązkowo włączaj.

server.properties dodatkowo

network-compression-threshold=256
max-tick-time=-1

network-compression-threshold=256 - kompresować pakiety większe niż 256 bajtów. Default też 256, ale upewnij się, że ta wartość jest ustawiona.

max-tick-time=-1 - wyłącza watchdog, który zabija serwer przy długim ticku. Na produkcji to kontrowersyjne ustawienie, ale zapobiegnie awaryjnym restartom przy krótkotrwałych lagach.

Kiedy lagi - to nie lagi, tylko atak

Zdarza się sytuacja: wszystko zoptymalizowałeś, TPS stabilne 20, ale gracze i tak narzekają na lagi. Albo odwrotnie - TPS nagle spada do 5, chociaż nic się nie zmieniło.

Kilka znaków, że to nie zwykłe lagi:

• Gwałtowny spadek TPS bez widocznej przyczyny - nikt nie wszedł, żaden nowy plugin nie był stawiany, a TPS spadł
• Timeouty sieciowe - gracze nie mogą się połączyć albo wylatują z błędem "Timed out"
• Wysokie obciążenie sieci przy normalnym obciążeniu CPU
• Masowe podłączenia - w logach dziesiątki albo setki prób połączenia na sekundę

To może być DDoS albo atak botowy. Atak sieciowy zapycha łącze albo przeciąża serwer fake'owymi połączeniami, i to wygląda jak lagi, chociaż sam Minecraft działa normalnie.

Jeśli obserwujesz takie symptomy, samymi configami tego nie załatwisz. Trzeba filtrowania ruchu na poziomie sieci. Właśnie do tego istnieją serwisy takie jak MineGuard - filtrują ruch, zanim trafi na twój serwer, i odcinają niechciane połączenia. Jeśli już był atak albo chcesz się zabezpieczyć z góry - ma sens skonfigurować taką ochronę.

Checklist optymalizacji

Podsumowanie. Oto kolejność działań przy lagach:

1. Sprawdź TPS i MSPT przez /spark tps - zrozum skalę problemu
2. Odpal spark profiler - znajdź, co konkretnie spowalnia
3. Sprawdź liczbę encji - najczęstsza przyczyna
4. Skonfiguruj entity activation range w spigot.yml
5. Zmniejsz simulation-distance do 4-5
6. Włącz optymalizacje Papera - optimize-explosions, per-player-mob-spawns, alt-item-despawn-rate
7. Używaj ALTERNATE_CURRENT dla redstone'a
8. Zastosuj flagi Aikara dla JVM
9. Pregeneruj świat z Chunky
10. Sprawdź pluginy przez spark pod kątem ciężkich obsługiwaczy

Jeśli po wszystkich optymalizacjach problem zostaje - sprawdź, czy nie atakują twojego serwera. Problemy sieciowe nie rozwiązują się configami Minecrafta.