Optimalizace je užitečná nejenom pro servery, které mají problémy při připojení více hráčů, ale i pro servery s menším počtem hráčů. Po správné optimalizaci se serveru výrazně sníží využití CPU a RAM a umožní tak na serveru hrát více hráčům současně bez záseků.
Jádro serveru
Před tím, než se vrhneme na samotnou optimalizaci a úpravu nastavení serverů je potřeba server přeinstalovat na Paper, pokud jej již využíváte, zkontrolujte, zda se jedná o nejnovější verzi.
V Administraci je možné povolit automatické aktualizace jádra serveru, které během spouštění serveru automaticky aktualizují server.jar. Nejnovější verze Paperu je také možné stáhnout z oficiálních stránek .
Java flagy
Flagy upravují chování Javy a její správy paměti. Bez aktivace flagů se může paměť RAM zaplnit častěji a tak způsobovat záseky při jejím čištění. Paper poskytuje možnost zobrazení statistik během čištění paměti pomocí příkazu timings paste po zadání příkazu se vygeneruje odkaz po jehož rozkliknutí uvidíme co nejvíce server zatěžuje.
Pokud máme u spodního čísla vyšší hodnotu než nula i po aktivaci java flagů znamená to, že serveru dochází paměť a nestíhá ji promazávat za běhu serveru bez dopadu na jeho výkon.
View distance & Simulation distance
Jednou z nejvíce zatěžujících funkcí v novějších verzích je načítání a aktualizace chunků.
K dispozici máme dvě nastavení ve verzi 1.18.x a výše:
Simulation distance je vzdálenost od hráče, ve které se budou dít věci. Patří sem vypékaní v pecích, růst plodin a stromů atd.
View distance nám určuje kolik chunků se hráčovi pošle tzv. do jaké vzdálenosti uvidí, je to podobné no-tick-view-distance v nižších Minecraft verzích 1.17.2 a méně
Díky této funkci můžeme snížit simulation distance v nastavení serveru (server.properties) na hodnotu 4-6, v této oblasti budou růst stromy, obilí, atd… Následně ve stejném souboru najdeme položku view-distance, která je ve výchozím nastavení nastavena na 10, zde nastavíme hodnotu mezi 6-10 tato oblast bude zasílána hráčům.
Ve výchozím nastavení je simulation distance 10 chunků na každou stranu, jeden hráč tedy načítá až 441 chunků, po snížení simulation distance na 4 se počet načtených chunků sníží na 81 což je pouze ±19%
Je potřeba, aby byla hodnota simulation-distance menší než standartní view-distance, jinak tato funkce nebude mít žádný vliv.
Žlutá oblast znázorňuje chunky, ve kterých budou růst stromy, obilí, atd… Modrá oblast jsou chunky, které jsou pouze načteny, ale nic se v nich neděje tj. nerostou stromy, mobové se nehýbou,…
Optimalizace souborů paper.yml, spigot.yml, bukkit.yml, …
Pokud se i po snížení simulation distance server stále chová nestabilně nebo se seká bude nejspíše problém v počtu entit(mobové, itemy na zemi, …) na serveru, tento problém se nejjednodušeji detekuje pomocí timings, kde se veškeré entity počítají do kategorie entityTick.
Nastavení ovlivňující entity jsou primárně entity-activation-range v souboru spigot.yml
Na internetu existuje spousta návodů jak optimalizovat server, proto jsme ze všech vybrali dvě stránky, které vám budou nápomocné při optimalizaci vašeho serveru.
Jednodušší návod, který se na nachází na githubu zde nám vysvětlí základní principy serveru a provede nás důležitými nastaveními.
“Složitější” návod, jedná se spíše o dokumentaci k optimalizaci serveru, nalezneme zde. Doporučili bychom jej spíše lidem, kteří se chtějí do hloubky zajímat o Paper a jeho možnostech nastavení a optimalizace.
Neexistuje jediné nastavení, které by fungovalo pro každý server. Měli byste si přečíst a pochopit každou dostupnou možnost konfigurace a podle toho upravit čísla tak, aby odpovídala vašim jedinečným podmínkám. Optimální konfigurace pro váš server se bude lišit v závislosti na hardwaru serveru, průměrném počtu hráčů a pluginech.
Jakékoliv uvedené hodnoty v optimalizačních návodech slouží jako ideální příklad, které na vašem serveru mohou zlepšit optimalizaci, ale také nemusí.
Předgenerace mapy
Pokud spouštíme nový server bez objevené mapy bude se při pohybu do neobjevených chunků mapa postupně generovat, při menším počtu hráčů < 10 generace chunků není tolik znatelná ovšem při větším počtu hráčů, kteří chodí po mapě a generují nové oblasti se může server začít sekat.
Bude-li na serveru hrát více hráčů současně je doporučeno mapu předgenerovat pomocí pluginu Chunky v tomto návodu také budeme používat addon ChunkyBorder, který hráčům zamezí chodit za border.
Po přidání obou pluginů a následném připojení na server spustíme postupně tyto příkazy:
- /chunky world world (příkazem zvolíme jaký svět budeme předgenerovávat)
- /chunky center 0 0 (nastaví střed generované oblasti)
- /chunky radius 5000 (počet bloků na každou strannu, které budou předgenerovány)
- /chunky border add (přidá do světa border, takže hráči nebudou moct jít do nepředgenerovaného světa)
- /chunky start (započne proces předgenerace)
Pro menší servery by měl být plně dostačující radius 5000 bloků, pro větší servery je samozřejmně potřeba radius navýšit, aby měli hráči větší plochu, po které se mohou pohybovat. Při výběru radiusu však pamatujte, že čím větší bude, tím více času zabere předgenerace mapy a také bude zabráno více úložiště.
Pokud vás zajímá kolik místa předgenerace zabere, tak lze využít tuto stránku.
Generace zabere nějaký čas, její postup je zobrazován v konzoli.
Pluginy
Často snížení TPS způsobují pluginy, které jsou špatně naprogramovány a zbytečně zatěžují server i při jednoduchých úlohách. Příkladem může být například plugin RealScoreboard, který dokáže při pouhém zobrazování tabulky scoreboard způsobit téměř 30% celkového využití procesoru. Tento typ pluginu lze jednoduše nalézt pomocí timings, které mohou vypadat následovně
Dalším pluginem je dynmapa, jejíž zatížení nelze zjistit pomocí timings, jelikož renderování mapy provádí na jiném procesu, který se v timings nezobrazuje, ale i tak způsobuje vyšší využití procesoru. Pokud máte na serveru přidanou dynmapu a často je Váš server dosahuje vysokého využití procesoru doporučujeme nastavení pluginu optimalizovat (návod na správné nastavení naleznete zde) nebo plugin kompletně odebrat.
Seznam výběru kvalitních pluginů naleznete na této stránce, které můžete využít k vývoji serveru.
Datapacky
Pokud na serveru používáte datapacky a i po optimalizaci z předchozích sekci je využití CPU vysoké nebo se server seká je dosti pravděpodobné, že jeden z datapacků je neoptimalizovaný a zbytečně server zatěžuje. Nejjednodušší způsob jak zjistit, co nejvíce vytěžuje server jsou timings (přikaz /timings paste). Datapacky spadají do sekce Command Functions.
Podle toho, která z funkcí je nejvíce náročná lze určit, jaký datapack má zátěž na svědomí, v tomto konkrétním případu se jednalo o datapack, který vytvářel neviditelné item framy.
Paper/Purpur forky
Slovo fork se používá pro pojmenování na čem je daná platforma postavená, tzv. jakou původní platformu modifikuje.
Např. Paper je fork Spigotu, v češtině bychom řekli: Paper je postaven na kódu Spigotu.
Místo Paperu, což je fork Spigotu lze také používat jiné forky. Tyto forky dokáží více stabilizovat Váš server, ale také udělat přesný opak.
Forky, které doporučujeme jsou:
- Paper - Nejoblíbenější serverový software, jehož cílem je zlepšit výkon a zároveň opravit nesrovnalosti v hratelnosti a herních mechanikách.
- Pufferfish - Paper fork, jehož cílem je další zlepšení výkonu serveru.
- Purpur - Pufferfish fork zaměřený na funkce a svobodu přizpůsobení.
Forky, kterým byste se měli vyvarovat:
- Jakýkoli placený serverový JAR, který tvrdí, že je asynchronní
- Bukkit/CraftBukkit/Spigot - Extrémně zastaralé z hlediska výkonu ve srovnání s jeho forky (Paper, Pufferfish, Purpur)
- Mnoho dalších forků od Pufferfish nebo Purpuru se bude potýkat s nestabilitou a dalšími problémy. Pokud usilujete o větší nárůst výkonu, optimalizujte svůj server.
Po stažení daného forku, server zálohujte. Následně stačí jít do Správce souborů v administraci a vymazat starý server.jar a nahradit ho s tím, že přejmenujete soubor na server.jar.
Druhý postup je využití záložky Reinstalace, kde se jak Paper, tak Purpur nachází.
