/
mc-node.net →
Minecraft

Jak naprawić lagi na serwerze za pomocą profilera Spark?

Zaktualizowano 31/08/20264 min czytania
W tym artykule
  1. Najpierw podstawy: TPS, MSPT i „Can't keep up”
  2. Krok 1: Zainstaluj Sparka
  3. Krok 2: Profiluj w trakcie lagów
  4. Krok 3: Odczytaj raport
  5. Częste przyczyny i ich rozwiązania
  6. Dalsza optymalizacja

Twój serwer wyraźnie zwalnia: bloki wracają po zniszczeniu, moby zamierają, komendy reagują z opóźnieniem, a w konsoli pojawia się Can't keep up! Is the server overloaded?. Nie musisz zgadywać, która farma albo który plugin zawinił — darmowy profiler Spark dokładnie mierzy, gdzie każdy tick traci czas. W tym poradniku zainstalujesz Sparka, zrobisz profil w trakcie lagów i zamienisz raport na konkretną poprawkę.

Najpierw podstawy: TPS, MSPT i „Can't keep up”

Serwer Minecraft działa w tempie 20 ticków na sekundę (TPS). W każdym ticku serwer aktualizuje cały świat i ma na to maksymalnie 50 milisekund. MSPT (milliseconds per tick) to czas, jaki tick faktycznie zajmuje. Dopóki MSPT trzyma się poniżej 50, serwer płynnie osiąga 20 TPS; gdy go przekroczy, TPS spada i dosłownie wszystko na serwerze zwalnia.

Komunikat Can't keep up! Is the server overloaded? Running 2000ms or 40 ticks behind oznacza dokładnie to: ticki trwały za długo, serwer nie nadąża i pomija ticki, żeby nadrobić zaległości. Jednorazowo przy starcie to nic groźnego; jeśli komunikat wraca podczas gry, masz prawdziwe lagi serwera.

Najpierw sprawdź, czy problem na pewno leży po stronie serwera. Niskie FPS lub przycinający się obraz (zwłaszcza z shaderami) to lagi klienta; rubberbanding przy wysokim pingu to lagi połączenia. Wpisz /spark tps: jeśli widzisz równe 20 TPS przy niskim MSPT, szukaj przyczyny po stronie klienta lub sieci.

Krok 1: Zainstaluj Sparka

  1. Jeśli używasz Papera lub Purpura 1.21 lub nowszego, Spark jest już wbudowany. Wpisz spark tps w zakładce Console panelu MC-Node; jeśli dostaniesz odpowiedź, przejdź od razu do kroku 2.
  2. W przeciwnym razie pobierz Sparka ze strony spark.lucko.me/download. Wybierz wersję Bukkit dla Paper/Spigot albo wersję Fabric/Forge/NeoForge dla serwera z modami.
  3. Otwórz zakładkę Files w panelu i wgraj plik jar do folderu plugins (na serwerze z modami: mods).
  4. Zrestartuj serwer z zakładki Console i sprawdź komendą spark tps, że wszystko działa.

Krok 2: Profiluj w trakcie lagów

Największa pułapka: profilowanie pustego lub świeżo zrestartowanego serwera. Bez graczy farmy, hoppery i chunki odpowiedzialne za lagi po prostu nie pracują, więc raport niczego nie pokaże. Uruchom profiler dokładnie wtedy, gdy lagi naprawdę występują, z graczami online.

  1. Poczekaj, aż lagi się pojawią, albo poproś graczy o odtworzenie sytuacji (na przykład przy podejrzanej farmie).
  2. Wpisz w konsoli: spark profiler start --timeout 300. Profiler mierzy przez 5 minut i zatrzymuje się sam. Bez --timeout zatrzymasz go ręcznie komendą spark profiler stop.
  3. Niech wszyscy grają normalnie dalej; sam pomiar prawie nie obciąża serwera.
  4. Po zakończeniu konsola wypisze link do spark.lucko.me. Otwórz go w przeglądarce.

Krok 3: Odczytaj raport

  1. U góry widzisz TPS i MSPT z czasu pomiaru — tak potwierdzisz, że faktycznie udało się uchwycić lagi.
  2. Otwórz drzewko pod wątkiem serwera i rozwijaj za każdym razem wiersz z najwyższym procentem. W ten sposób dojdziesz do zadania, które pochłania najwięcej czasu ticka.
  3. Rozpoznaj wzorce: dużo czasu w entityTick lub AI mobów wskazuje na zbyt wiele entities; HopperBlockEntity na linie hopperów; chunk generation lub ServerChunkCache na ładowanie chunków; a nazwa pakietu w stylu com.przyklad.nazwapluginu wskazuje konkretny plugin jako winowajcę.

Częste przyczyny i ich rozwiązania

  • Za dużo entities — Zwykle farmy mobów albo porozrzucane przedmioty. Ustaw /gamerule maxEntityCramming 8 (domyślnie 24), obniż spawn-limits w bukkit.yml oraz entity-activation-range w spigot.yml, a dużym farmom dodaj włącznik.
  • Hoppery — Długie linie hopperów sprawdzają zawartość w każdym ticku. Zwiększ w bukkit.yml wartość ticks-per.hopper-transfer (na przykład z 8 na 16), a na Paperze ustaw w config/paper-world-defaults.yml opcję hopper.cooldown-when-full na true. Bardzo długie linie zastąp strumieniami wody z mniejszą liczbą hopperów.
  • Ładowanie chunków i generowanie świata — Eksplorujący gracze zmuszają serwer do generowania nowych chunków. Obniż w server.properties wartość simulation-distance (na przykład do 6) i ewentualnie view-distance, ustaw granicę świata i wygeneruj świat z wyprzedzeniem pluginem Chunky: /chunky radius 3000, a następnie /chunky start.
  • Jeden plugin na szczycie raportu — Najpierw zaktualizuj plugin, wyłącz ciężkie funkcje (skany, animacje, hologramy) w jego configu albo poszukaj lżejszej alternatywy. Możesz to przetestować, przenosząc tymczasowo plik jar poza folder plugins i restartując serwer.
  • „Can't keep up” tylko przy starcie — Nic groźnego: serwer nadrabia pik startowy. Reaguj tylko wtedy, gdy komunikat wraca podczas normalnej gry.
  • TPS wynosi 20, a gracze i tak narzekają — To lagi klienta lub sieci: zmniejsz render distance albo wyłącz shadery po stronie klienta, albo sprawdź ping.

Dalsza optymalizacja

Pracujesz jeszcze z /timings? Nasz artykuł o tworzeniu timings jest przestarzały; Spark to jego nowoczesny następca. Strukturalne usprawnienia znajdziesz w naszym poradniku optymalizacji, a o tym, czy winowajcą jest zbyt mała ilość pamięci, przeczytasz w poradniku o RAM. Nadal nie działa? Otwórz ticket przez naszą stronę pomocy i wklej link do swojego raportu Spark — chętnie na niego zerkniemy.