Optymalizacja serwera Minecraft: paper.yml, spigot.yml i bukkit.yml od podstaw

Większość poradników o optymalizacji serwera Minecraft każe wkleić pięćdziesiąt linijek do paper.yml. Problem w tym, że ten plik nie istnieje od wersji 1.19, bo Paper rozbił go na dwa osobne pliki w katalogu config. Poniżej rozkładamy, które parametry w server.properties, spigot.yml, bukkit.yml i plikach Paper faktycznie zmieniają wydajność, ile dokładnie wpisać i jakim kosztem, bo każda z tych zmian coś zabiera w zamian.

Krótka odpowiedź: sześć zmian, które dają najwięcej

Jeśli masz zmienić tylko kilka rzeczy, zmień te. Odpowiadają za zdecydowaną większość realnego zysku na typowym serwerze z pluginami, a ich skutki uboczne są przewidywalne.

Zanim cokolwiek zmienisz, zmierz, co faktycznie boli

Optymalizacja bez pomiaru to zgadywanie. Serwer może się dławić od jednego źle napisanego pluginu, a Ty przez tydzień będziesz obniżać zasięg widzenia i zastanawiać się, dlaczego nic nie pomaga. Trzy narzędzia mówią niemal wszystko.

1. 1

   /tps, czyli czy serwer w ogóle nadąża

   20 TPS to stan zdrowy i jednocześnie maksimum, wyżej nie będzie. Spadek do 18 jest już odczuwalny, a poniżej 15 gra zaczyna się zacinać przy każdym uderzeniu i otwarciu skrzynki. Paper pokazuje trzy liczby: średnią z minuty, pięciu i piętnastu minut.
2. 2

   /mspt, czyli ile milisekund zajmuje jeden tik

   To ważniejsza liczba niż TPS. Serwer ma na tik 50 ms. Jeśli mieścisz się w 30 ms, masz zapas. Przy 45 ms TPS jeszcze pokazuje 20, ale jesteś pół kroku od spadku, i właśnie z tego powodu serwer zaczyna lagować dopiero wtedy, gdy dojdzie dwóch graczy.
3. 3

   spark, czyli co konkretnie zjada te milisekundy

   Paper wycofał stary mechanizm Timings na rzecz sparka i to on jest dziś właściwym narzędziem. Odpal /spark profiler start w godzinach szczytu, daj mu kilka minut, zatrzymaj i otwórz raport. Dostajesz drzewo wywołań z nazwami pluginów i procentem czasu. Bez tego naprawiasz po omacku.

Gdzie naprawdę leżą te pliki (i dlaczego paper.yml zniknął)

Od Minecrafta 1.19 Paper nie używa już jednego pliku paper.yml, bo jego zawartość została rozdzielona na config/paper-global.yml z ustawieniami całego serwera i config/paper-world-defaults.yml z ustawieniami świata. Migracja jest automatyczna przy pierwszym starcie, ale każdy poradnik pisany przed tą zmianą wysyła Cię w nieistniejące miejsce.

server.properties: dwa parametry ważniejsze niż cała reszta razem

Jeśli masz zmienić dokładnie jedną rzecz w całym serwerze, zmniejsz simulation-distance. To on decyduje, jak daleko od gracza serwer liczy moby, wzrost roślin, redstone i mechanizmy, czyli bezpośrednio ile pracy wykonuje procesor w każdym tiku.

view-distance=7
simulation-distance=5
entity-broadcast-range-percentage=75
network-compression-threshold=256
sync-chunk-writes=false
max-tick-time=60000

• view-distance to promień w chunkach, jaki serwer wysyła klientowi. Zejście z 10 na 7 to spadek liczby chunków na gracza o niemal połowę. Gracze zauważają to głównie w widokach na duże odległości, więc na serwerze survivalowym 7 jest praktycznie niewyczuwalne, a na serwerze z mapą pod budowanie panoram już tak.
• simulation-distance to promień, w którym cokolwiek się dzieje. Wartość 5 oznacza, że farma oddalona o sześć chunków od gracza staje. Dla większości serwerów to zaleta, ale dla serwera technicznego z farmami na AFK jest to poważna zmiana mechaniki, którą trzeba ogłosić.
• entity-broadcast-range-percentage skaluje dystans, z którego klient dostaje informacje o encjach. 75 procent zmniejsza ruch sieciowy i pracę po stronie klienta, co pomaga zwłaszcza na serwerach z tłumem na spawnie.
• sync-chunk-writes=false pozwala zapisywać chunki asynchronicznie i zdejmuje zauważalne zacięcia przy autosave. Ryzyko utraty paru sekund świata przy twardym ubiciu procesu jest realne, ale akceptowalne przy poprawnych kopiach zapasowych.
• network-compression-threshold zostaw na 256, chyba że serwer stoi za proxy na tej samej maszynie. Wtedy -1 wyłącza kompresję i oszczędza CPU, bo ruch nie opuszcza localhosta. Przy połączeniach przez internet wyłączenie kompresji znacząco zwiększy transfer.

spigot.yml: zasięgi encji, scalanie itemów i leje

W spigot.yml najwięcej daje skrócenie zasięgów śledzenia encji i agresywniejsze scalanie wyrzuconych itemów, bo oba zmniejszają liczbę obiektów, o których serwer musi pamiętać i które musi rozsyłać do klientów. Wszystko poniżej wpisujesz w sekcji world-settings: default:.

entity-tracking-range:
  players: 48
  animals: 32
  monsters: 32
  misc: 24
  other: 48
  display: 128
merge-radius:
  item: 3.5
  exp: 6.0
mob-spawn-range: 5
item-despawn-rate: 4000
arrow-despawn-rate: 600
hopper-transfer: 8
hopper-check: 8
hopper-amount: 3
nerf-spawner-mobs: true
save-user-cache-on-stop-only: true

bukkit.yml: limity spawnu, czyli ile mobów może żyć naraz

bukkit.yml zmienia się rzadko, ale gdy na serwerze żyje kilkaset mobów na gracza, obniżenie spawn-limits daje więcej niż dowolna inna zmiana. Limity są liczone per gracz, więc na serwerze z trzydziestoma osobami mnożą się bardzo szybko.

spawn-limits:
  monsters: 50
  animals: 8
  water-animals: 3
  water-ambient: 10
  ambient: 1
ticks-per:
  monster-spawns: 2
  animal-spawns: 400
  water-spawns: 400
  ambient-spawns: 400
  autosave: 6000
chunk-gc:
  period-in-ticks: 400

• monsters: 50 zamiast domyślnych 70 to mniej potworów do tykania i mniej kolizji. Na serwerze survivalowym gracze tego nie zauważą, bo limit i tak rzadko jest osiągany z dala od jaskiń.
• ambient: 1 to nietoperze. Nie wnoszą nic poza dźwiękiem i pracą dla serwera.
• monster-spawns: 2 oznacza próbę spawnu co dwa tiki zamiast co tik. To połowa pracy spawnera przy niemal niezmienionej liczbie mobów, bo limit populacji i tak jest wąskim gardłem.
• autosave: 6000 przenosi zapis świata na raz na pięć minut. Rzadszy zapis to rzadsze zacięcia, ale też więcej do stracenia przy awarii, więc ma sens tylko razem z działającymi kopiami zapasowymi.

paper-world-defaults.yml: tu leży najwięcej realnych zysków

Ten plik zawiera optymalizacje, których Spigot nie ma w ogóle, i z tego powodu samo przejście z Spigota na Paper jest największą optymalizacją, jaką możesz zrobić. Poniżej ustawienia, które dają wymierny efekt bez psucia mechaniki.

chunks:
  max-auto-save-chunks-per-tick: 8
  delay-chunk-unloads-by: 10s
  prevent-moving-into-unloaded-chunks: true
collisions:
  max-entity-collisions: 2
entities:
  armor-stands:
    tick: false
  behavior:
    disable-chest-cat-detection: true
    experience-merge-max-value: 16
  spawning:
    despawn-ranges:
      monster:
        soft:
          horizontal: 28
          vertical: 28
        hard:
          horizontal: 96
          vertical: 96
    per-player-mob-spawns: true
    alt-item-despawn-rate:
      enabled: true
environment:
  optimize-explosions: true
  treasure-maps:
    find-already-discovered:
      loot-tables: true
hopper:
  disable-move-event: true
  ignore-occluding-blocks: true
misc:
  redstone-implementation: ALTERNATE_CURRENT
tick-rates:
  mob-spawner: 2
  sensor:
    villager:
      secondarypoisensor: 80
  behavior:
    villager:
      validatenearbypoi: 120

Redstone: jedna zmiana, która bywa warta więcej niż reszta pliku

Klucz misc.redstone-implementation siedzi w paper-world-defaults.yml, a nie w pliku globalnym, i to pomyłka, którą powtarza połowa poradników. Domyślnie stoi na VANILLA, a do wyboru są jeszcze EIGENCRAFT i ALTERNATE_CURRENT. Ten ostatni to przepisany od zera algorytm, który aktualizuje tylko to, co faktycznie się zmieniło, więc w układach z dużą ilością pyłu bywa wielokrotnie szybszy od waniliowego.

paper-global.yml: kilka drobiazgów na koniec

Plik globalny ma niewiele do zaoferowania pod kątem wydajności, bo większość przełączników siedzi w konfiguracji świata. Te trzy warto jednak znać.

misc:
  region-file-cache-size: 256
player-auto-save:
  rate: -1
  max-per-tick: -1
chunk-system:
  io-threads: -1

Wartość -1 w player-auto-save oznacza, że serwer bierze częstotliwość z ticks-per.autosave w bukkit.yml i sam dobiera rozsądny limit zapisów na tik, więc jeśli ustawiłeś tam 6000, nie musisz ruszać już niczego więcej. io-threads poniżej zera oznacza jeden wątek na operacje dyskowe, co dla małego i średniego serwera jest w zupełności wystarczające.

Flagi JVM: to nie konfiguracja serwera, ale liczy się równie mocno

Najlepiej przetestowany zestaw flag dla serwerów Minecraft to tak zwane flagi Aikara, czyli konfiguracja garbage collectora G1, która zamienia rzadkie długie przestoje na częste i krótkie. Efektu nie zobaczysz w średnim TPS, tylko w zniknięciu regularnych sekundowych zacięć.

java -Xms8G -Xmx8G \
  -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

• -Xms równe -Xmx to celowa decyzja, nie oszczędność pamięci. Sterta, która nie rośnie, nie wymusza kosztownych zmian rozmiaru w trakcie gry.
• Powyżej 12 GB pamięci zestaw się zmienia: G1NewSizePercent=40, G1MaxNewSizePercent=50, G1HeapRegionSize=16M, G1ReservePercent=15 i InitiatingHeapOccupancyPercent=20.
• Nie przydzielaj serwerowi całej dostępnej pamięci. JVM potrzebuje miejsca poza stertą na metaspace, wątki i bufory sieciowe, więc zostaw około 1 do 2 GB zapasu. Inaczej proces zostanie ubity przez system zanim zobaczysz błąd z Javy.
• Nie doklejaj flag z kilku poradników do siebie. Zestawy bywają sprzeczne, a -XX:+UseZGC obok -XX:+UseG1GC to najszybszy sposób, by serwer nie wstał.

Gotowe zestawy dla trzech typów serwera

Różne serwery mają różne wąskie gardła, więc jeden uniwersalny zestaw nie istnieje. Poniżej punkty wyjścia, od których warto zacząć i które potem dociąga się pomiarami.

Pięć rzeczy, które wyglądają jak optymalizacja, a nią nie są

• Dosypanie RAM-u do serwera, który nie ma problemu z RAM-em. Lagi z komunikatem Can't keep up to problem z procesorem i jednym wątkiem. Więcej pamięci nie przyspieszy liczenia tiku, a zbyt duża sterta wydłuża przestoje garbage collectora.
• Kopiowanie cudzego configa w całości. Pliki z poradników odnoszą się do starszych wersji i zawierają klucze, których Twój build już nie zna. Paper zignoruje nieznane klucze po cichu, więc będziesz przekonany, że coś ustawiłeś.
• Wyłączanie watchdoga. Maskuje problem zamiast go rozwiązać i zabiera Ci jedyny log, z którego dałoby się coś wyczytać.
• Wyłączanie wszystkiego, co da się wyłączyć. Serwer z wyłączonym AI mobów, zerowym despawnem i obciętym tickiem encji ma świetne TPS i nie nadaje się do gry. Optymalizacja to szukanie najlepszego stosunku zysku do odebranej graczom mechaniki.
• Trzymanie dziesięciu pluginów robiących to samo. Każdy plugin nasłuchuje zdarzeń. Trzy pluginy pilnujące terenu to trzykrotna praca przy każdym postawionym bloku, a to jedno z najczęstszych zdarzeń na serwerze.

Najczęstsze pytania

Czy paper.yml jeszcze istnieje?

Nie. Od Minecrafta 1.19 Paper używa config/paper-global.yml i config/paper-world-defaults.yml. Stary paper.yml jest migrowany automatycznie przy pierwszym uruchomieniu nowszego builda i przestaje być odczytywany.

Co obniżyć pierwsze, view-distance czy simulation-distance?

Najpierw simulation-distance. Odpowiada za faktyczne liczenie mobów i mechanizmów, więc daje większy zysk na procesorze, a gracze zauważają go mniej niż skrócenie zasięgu widzenia. Zasięg widzenia obniżaj dopiero w drugiej kolejności.

Czy te ustawienia działają na Purpurze i Pufferfish?

Tak, bo oba są pochodnymi Paper i dziedziczą całą jego konfigurację. Dodatkowo mają własne pliki, odpowiednio purpur.yml i pufferfish.yml, z kolejnymi opcjami, w tym agresywniejszymi optymalizacjami AI mobów.

Po ilu minutach widać efekt zmiany?

TPS i MSPT reagują od razu po restarcie, ale wiarygodny pomiar wymaga normalnego ruchu, więc najlepiej porównać /mspt w tej samej godzinie szczytu przed i po. Zmiany dotyczące chunków i despawnu mobów widać dopiero po kilkudziesięciu minutach, gdy świat się przewietrzy.

Czy zmniejszenie view-distance obniży ping graczy?

Nie obniży samego pingu, bo ten zależy od odległości do serwera i jakości łącza. Zmniejszy natomiast ilość danych wysyłanych do klienta, co pomaga graczom na słabszym łączu i usuwa zacięcia przy wchodzeniu w nowy teren.

Czy mogę edytować te pliki przy włączonym serwerze?

Możesz je zapisać, ale serwer odczytuje konfigurację przy starcie, więc zmiany zadziałają po restarcie. Dodatkowo serwer nadpisuje część plików przy zatrzymaniu, więc edycja na żywo może zostać po prostu skasowana. Bezpieczniej zatrzymać serwer, zmienić plik i wystartować.