Czemu mam takie lagi?!?

Wymagania

• Silnik Paper lub jego forki (Purpur, etc.)
• Plugin spark (domyślnie wgrany od Paper'a 1.21 oraz każdej wersji Purpur'a) - Służy do mierzenia wydajności serwera i dokładnego namierzania źródła lagów
• Plugin OptimizationUtils - dodaje mase przydatnych komend do namierzania/naprawiania lagów.

Sprawdź TPS'y oraz MSPT

Wpisz /spark tps aby sprawdzić ile serwer ma TPS'ów. Ta komenda powinna dać ci coś takiego:

Omówmy sobie co te wszystkie liczby znaczą:

TPS - ile ticków serwer wykonał w ciągu sekundy.

Na przedstawionym obrazku na dole widać 5 liczb. Każda z nich to liczba TPS'ów dla odpowiedniego przedziału czasu. Czyli:

• 5s - średnia liczba TPS'ów w ciągu ostatnich 5 sekund
• 10s - średnia liczba TPS'ów w ciągu ostatnich 10 sekund
• 1m - średnia liczba TPS'ów w ciągu ostatniej minuty
• 5m - średnia liczba TPS'ów w ciągu ostatnich 5 minut
• 15m - średnia liczba TPS'ów w ciągu ostatnich 15 minut

MSPT - ile milisekund zajęło serwerowi wykonanie jednego ticka.

Skoro 20 ticków musi wykonać się w 1 sekundę to znaczy że maksymalne MSPT wynosi 1000ms / 20 = 50ms. Inaczej jeśli przekroczy tą wartość to TPS'y będą spadać, czyli serwer będzie lagował.

Często jest to dużo bardziej wiarygodna metryka niż TPS'y, ponieważ dzięki MSPT można przewidzieć kiedy TPS'y zaczną spadać. Jeśli MSPT będzie wynosić 45ms to znaczy że serwer trzyma już się na krawędzi aby TPS'y zaczęły spadać.

Sciąga komend

Szukanie problemu:

• /spark tickmonitor - pokazuje ci na czacie kiedy był lag i ile trwał
• /ou info - view distance (globalny i per player), simulation distance, random tick speed
• /spark profiler open - uruchamia sparka, aby znaleźć dokładne źródło lagów.
• /paper entity list - pokazuje ilość mobów na świecie
• /perf start - rozpoczyna profiling. W katalogu debug tworzy się .zip z pomiarem wydajności.

Akcje:

• /gamerule random_tick_speed 0 - wyłącza random tick.
• /ou setsimulationdistance 3 - ustawia simulation distance na wszystkich światach.
• /ou setviewdistance 6 - ustawia render distance dla wszystkich graczy.
• /ou killanimalsoutofrange 64 - zabija zwierzęta które są daej od graczy o 64 bloki

Znane problemy i rozwiązania

1. Zbyt wiele chunków

Dużo chunków musi serwer przetworzyć w ciągu jednego ticka. W tym przedziale następuje między innymi tickowanie mobów, random tick (czyli rośnięcie trawy, bamsusów, rozprzestrzenianie się ognia itp.)

Jak naprawić

• /ou info - sprawdzić jakie view distance mają ustawione gracze
• /ou setviewdistance 6 - dostosować owy view distance poprzez zmniejszenie go
• /ou setsimulationdistance 3 - zmniejszyć obszar w którym może się cokolwiek tickować.

2. Zbyt dużo mobów

Dużo mobów musi serwer przetworzyć w ciągu jednego ticka.

Na tym przykładzie powyższego sparka widać że najwięcej zasobów serwera zabierają ogólnie Animals - Rabbit, Chicken, Sheep ale i również Villagerzy.

Jak naprawić

• /paper entity list - sprawdzić ile mobów jest na świecie.
• /ou killanimalsoutofrange 64 - zabija zwierzęta które są poza promieniem 64 bloków od graczy.
• /ou killoutofrange ENDERMAN 64 - jeśli chcesz się pozbyć jakiegoś konkretnego typu mobka poza promieniem 64 bloków od graczy.
• /gamerule spawn_mobs false (lub kiedyś /gamerule doMobSpawning false) - wyłącza kompletnie spawnowanie się mobów, jeśli nie chcesz aby w ogóle się spawniły.
• /perf start - rozpoczyna profiling. W katalogu debug tworzy się .zip z pomiarem wydajności. W zipie w server/profiling.txt można znaleźć jakie dokładnie moby powodują najwięcej lagów.
• Sam w sobie plugin OptimizationUtils posiada wbudowaną funkcje Dynamic Mobcap, która automatycznie dostosowuje mobcap do warunków panujących na serwerze.

3. Lagi związane z Random Tick

Zbyt często jest uruchamiany random tick (czyli rośnięcie trawy, bamsusów, rozprzestrzenianie się ognia itp.). Może to być spowodowanie zbyt dużą ilością załadowanych chunków lub po prostu zbyt dużą wartością ustawioną w /gamerule random_tick_speed

Jak naprawić

• /ou info - zobacz jaki jest ustawiony random tick speed na poszczególnych światach
• /gamerule random_tick_speed 0 (lub kiedyś /gamerule randomTickSpeed 0) - wyłącza kompletnie random tick.
• /ou setviewdistance 6 - zmniejsza ilość wczytanych chunków co również może z tym problemem pomóc.

4. Brakujący RAM

Po wpisaniu /spark tickmonitor można zauważyć bardzo częste cykle czyszczenia pamięci (GC).

Jak naprawić

• /ou setviewdistance 6 - zmniejsza ilość wczytanych chunków co również może z tym problemem pomóc.
• /spark heapdump - robi zrzut pamięci RAM do późniejszej analizy. Doświadczona osoba może go wykorzystać do znalezienia wycieku pamięci w pluginach.
• Dokupienie ramu - Optymalnie serwer potrzebuje około 6-10 GB RAMu (na silniku Paper z poprawnie zrobioną konfiguracją).

5. Wysoki ping, brak spadków TPSów (Ghost lag)

To jest jeden z trudniejszych lagów do namierzenia. Najczęściej jest on określany mianem 'Ghost Lag' lub 'Network Lag'. Ten lag nie pochodzi z głównego wątku serwera (dlatego TPSy są w normie), tylko z sieci - z przetwarzania pakietów albo z internetu hostingu.

Jak naprawić

• Sprawdzić pod F3 ilość wysyłanych pakietów tx/rx (tx - transmitted - wysyłane, rx - received - odbierane).
• /spark profiler start --thread * - mierzy wydajność wszystkich wątków serwera. Zobacz wątek Netty Epoll IO (odpowiedzialny za przetwarzanie pakietów).
• Upewnić się że kompresja pakietów jest włączona:
  • Paper: server.properties -> network-compression-threshold=256 - nie może być -1 (wyłączone)
  • Velocity: velocity.toml -> compression-threshold = 256 - nie może być -1 (wyłączone)