Výkon serveru Sons of the Forest: RAM, CPU a lagy

Dedikovaný server Sons of the Forest potřebuje pro malou skupinu zhruba 8 GB paměti a dvě rychlá jádra, pro zabydlenou skupinu čtyř až šesti hráčů 10 GB a pro plný server osmi hráčů na světě, který se hraje už týdny, 12 GB a tři jádra. Je náročný, protože drží v paměti velký, detailní svět a všechny kanibaly, zvířata i stavby simuluje v jednom hlavním vlákně, a na Linuxu k tomu přidává zátěž z běhu windowsové binárky pod Wine. Většinu využití CPU určují dva klíče v dedicatedserver.cfg - ActiveTargetFramerate a IdleTargetFramerate - a jeden, SaveInterval, určuje, kdy server sekne. Zbytek příběhu o výkonu je o čase: server, který běží tři dny, je pomalejší než ten samý server čerstvě spuštěný, a plánovaný restart spraví víc lagů než jakékoli nastavení.

Tento článek je o dimenzování a o tom, jak server udržet rychlý. Instalace, porty a všechny konfigurační klíče jsou v průvodci dedikovaným serverem Sons of the Forest, mechanika samotného Wine pak v článku Wine a Proton pro servery jen pro Windows. Nic z toho tu neopakuji víc, než je nutné.

Proč je server náročný#

K téhle hře lidé přicházejí z The Forest, jehož server pohodlně běžel ve 3 GB, a jsou překvapení, že pokračování chce víc než dvojnásobek. Rozdíl vysvětlují čtyři věci.

• Svět je velký a načtený. Ostrov je mnohem větší a hustší než v první hře a server drží stav všeho, co se na něm změnilo: skácené stromy, odložené předměty, zabité nepřátele, otevřené kontejnery, každý kmen a větev každé stavby. Tento stav roste, jak skupina prozkoumává a staví, a za běhu serveru se nezmenšuje.
• AI běží na serveru. Skupiny kanibalů, mutanti, zvířata i společníci jsou simulováni serverem, ne počítači hráčů. Víc aktivních hráčů na víc místech znamená víc AI vzhůru najednou a AI je nejdražší část každého ticku.
• Stavění je fyzika. Volné stavění v Sons of the Forest umisťuje jednotlivé klády a prkna místo hotových dílů a statické kontroly, které rozhodují, jestli něco udrží, jsou skutečná práce. Velká základna jsou tisíce objektů, z nichž každý je držen v paměti a synchronizován ke každému klientovi, který se připojí.
• Je to hra z Unity postavená pro klienta. Dedikovaný server je hra bez rendereru, ne účelově postavený štíhlý server. Hodně z toho, co si klient drží kolem sebe, zůstává i v paměti serveru.

Nic z toho není chyba. Je to prostě cena hry, jaká je, a znamená to, že nízké paměťové tarify vhodné pro Terrarii nebo Valheim jsou špatný výchozí bod. Obecnější úvaha - zjistit, na co hra opravdu spotřebovává paměť a CPU - je v článku CPU vs RAM u herních serverů.

RAM a CPU podle počtu hráčů#

Endnight nezveřejňuje hardwarové požadavky pro dedikovaný server, takže níže uvedená čísla jsou plánovací hodnoty z praxe, ne oficiální tabulka. Platí pro celý proces serveru a na Linuxu zahrnují vrstvu Wine.

Pár poznámek ke čtení té tabulky:

• Paměť určuje spíš svět než počet hráčů. Dva hráči s obrovskou základnou mohou spotřebovat víc než šest hráčů na mladém světě. Počet hráčů záleží proto, že víc lidí rozprostřených po ostrově probudí víc světa najednou a každý hráč, který se připojí, vtáhne do aktivního provozu další kus světa.
• 8 GB je minimum, ne pohodlný střed. Čerstvý server bude v klidu hluboko pod ním, což lidi svádí ke koupi menšího tarifu. Sleduj ho po týdnu hraní, ne po hodině.
• CPU je hlavně o jednom vlákně. Hlavní simulační smyčka je v praxi jednovláknová, takže jedno rychlé jádro má větší cenu než čtyři pomalá. Další jádra obstarávají ukládání, síť a přenos BlobSync k připojujícím se hráčům, a proto jsou dvě realistické minimum, i když hra "jen" používá jedno. Článek Jak číst využití CPU herního serveru vysvětluje, proč může být server na svém limitu, i když ukazuje 40 procent.
• Rychlost disku záleží ve dvou okamžicích: při načítání světa po startu a při zápisu světa při každém uložení. Instalace má 10-15 GB a každý slot s uložením desítky megabajtů, takže kapacita je málokdy problém; problém je latence.

Limit osmi hráčů je přímo ve hře, takže žádný "tarif pro 16 hráčů" plánovat nemusíš. Pokud uvažuješ, jestli by větší tarif pomohl serveru, který už rezervu má, nepomůže - obecný argument najdeš v článku kolik hráčů se vejde na server.

Cílové snímkové frekvence: ActiveTargetFramerate a IdleTargetFramerate#

Server nemá obrazovku, ale přesto běží herní smyčka a tyto dva klíče určují, kolikrát za sekundu se ji snaží spustit. Je to nejbližší věc, jakou má Sons of the Forest k nastavení tick rate, a je to hlavní páka na spotřebu CPU.

{  "IdleDayCycleSpeed": 0.0,  "IdleTargetFramerate": 5,  "ActiveTargetFramerate": 60,  "SaveInterval": 600}

Všimni si názvů. Návody a příspěvky na fórech tomu někdy říkají "TargetFps" nebo "TargetFramerate"; ani jeden z těch klíčů v souboru neexistuje. Server čte ActiveTargetFramerate a IdleTargetFramerate a chybně napsaný klíč v JSON konfiguraci se ignoruje, nikoli odmítne, takže překlep vypadá úplně stejně jako nastavení, které nic nedělá.

Co dělá idle cíl

Když nikdo není online, server klesne na pět průchodů smyčkou za sekundu. Proto prázdný server Sons of the Forest stojí skoro nic na CPU, a proto je server, který se zahřívá, když na něm nikdo není, příznakem něčeho jiného - probíhajícího ukládání, zaseknutého procesu nebo na Linuxu samotného Wine, které se chová špatně. Nech IdleTargetFramerate na 5. Zvyšovat ho nemá smysl: při IdleDayCycleSpeed nastaveném na 0.0 je světový čas v prázdném serveru stejně zamrzlý a rychlejší idle smyčka nemá co dělat.

Co dělá aktivní cíl

Když jsou hráči online, server míří na 60 průchodů smyčkou za sekundu. Každý průchod spustí AI, fyziku a aktualizace světa a pošle stav klientům. Když CPU nestíhá, server prostě běží méně průchodů, než je cíl, a hráči to vidí jako nepřátele, kteří se hýbou po skocích, zásahy, které dopadnou pozdě, a dveře nebo stavby, které reagují se zpožděním.

Snížení ActiveTargetFramerate je legitimní kompromis na serveru omezeném CPU. Při 30 server udělá zhruba polovinu simulační práce za sekundu a na tarifu, který je přišpendlený na svém limitu CPU, je výsledkem často plynulejší hra, ne horší, protože stabilních 30 působí lépe než cíl 60, který se při bojích neustále propadá na 20. Cenou jsou hrubší aktualizace: pohyb nepřátel a fyzika se vzorkují méně často, čehož si někteří hráči v boji zblízka všimnou. Endnight nedokumentuje, jak přesně jednotlivé podsystémy na cíl reagují, takže ber nastavení jako něco, co je třeba vyzkoušet s vlastní skupinou.

Pár pravidel pro orientaci:

• Nezvyšuj ho nad 60. Klienti z toho nic nemají a server utrácí CPU, kterého mívá málo.
• Snižuj po krocích - 60, pak 45, pak 30 - a na každém hraj jednu session. Měň vždy jednu věc, abys věděl, která změna pomohla.
• Snížení neušetří paměť. Svět má stejnou velikost při jakékoli snímkové frekvenci. Pokud je problém v paměti, tento klíč řešení není.
• Dá se nastavit z příkazové řádky jako -dedicatedserver.ActiveTargetFramerate "30", čímž ho řada panelů zpřístupňuje bez úpravy souboru.

Obecná myšlenka - co znamená cíl ticku nebo snímků pro server a proč stabilní frekvence porazí vysokou - je v článku co tick rate doopravdy znamená.

Autosave a záseky při ukládání#

Každých SaveInterval sekund - ve výchozím stavu 600 - server serializuje svět a zapíše ho do slotu s uložením. Na mladém světě to trvá okamžik. Na vyspělém světě s velkou základnou je to znatelný zásek: sekunda nebo víc, kdy se na serveru všechno zastaví, následovaná krátkým rubber-bandingem, než to klienti doženou.

Tento zásek je nejčastější hlášení o "náhodném lagu" na serveru Sons of the Forest a má charakteristický rys: je pravidelný. Pokud se stutter objevuje každých deset minut, přibližně ve stejné minutě každé hodiny, je to ukládání. Potvrdíš to sledováním konzole, kde v okamžiku stížností uvidíš řádek o uložení.

Co s tím můžeš dělat:

• Smířit se s tím. Jednosekundová pauza každých deset minut je cena za to, že při pádu nepřijdeš o deset minut práce. Většina skupin, jakmile se dozví, co to je, přestane to řešit.
• Prodloužit interval na 900 nebo 1200, pokud zásek opravdu vadí. Poloviční četnost znamená dvojnásobek toho, o co můžeš přijít při nečistém zastavení. Tenhle kompromis se vyplatí jen spolu se spolehlivými zálohami a čistými restarty.
• Nezkracovat ho kvůli jistotě na velkém světě. 300 na světě se základnou o pěti tisících kusech znamená viditelnou pauzu každých pět minut.
• Rychlý disk pauzu zkrátí, ale neodstraní; velká část času jde na shromáždění a serializaci stavu, ne na samotný zápis. Článek co NVMe opravdu mění je upřímný v tom, kde pomáhá.

Širší kompromisy časovačů ukládání, pro tuto hru i jiné, jsou v článku intervaly autosave u herních serverů.

Binárka jen pro Windows a co stojí Wine#

Endnight vydává dedikovaný server jen pro Windows. Na Linuxu, kde běží většina herního hostingu, se spouští pod Wine (nebo výjimečně Proton), obvykle s virtuálním displejem jako Xvfb, protože runtime Unity jeden očekává. Nastavení je popsáno v článku Wine a Proton pro servery jen pro Windows; pro dimenzování je důležitá cena.

• Paměť: o několik set megabajtů víc, než by stejný server použil na Windows, na proces Wine serveru, načtené windowsové knihovny a virtuální displej. Na tarifu s 12 GB je to šum; na tarifu s 8 GB je to část důvodu, proč je 8 GB minimum.
• CPU: malá v ustáleném hraní, protože kód hry běží nativně a překládají se jen systémová volání. Víc se projeví v momentech náročných na soubory - start, načtení světa a ukládání - což jsou přesně momenty, které už samy sekají.
• Šum v logu: vlastní diagnostický výstup Wine umí být upovídaný. Nastavení WINEDEBUG=-all v prostředí ho umlčí a na vytíženém serveru ušetří trochu CPU a disku.
• Citlivost na verzi: patch hry občas vyžaduje novější Wine. Pokud server, který běžel hladce, začne hned po aktualizaci sekat nebo padat a windowsoví hostitelé totéž nehlásí, prvním podezřelým je build Wine.

Na samotných Windows se nic z toho netýká, ale windowsový server stojí v klidu víc paměti než linuxový s Wine, takže self-hosting na windowsovém stroji není taková úspora, jak vypadá. Širší srovnání je v článku Linux vs Windows u herních serverů.

Dlouhé session: proč je server pomalejší#

Servery Sons of the Forest s uptime degradují. Server, který v pondělí večer běží hladce, může být ve čtvrtek citelně laggovitější se stejnými hráči dělajícími stejné věci a restart ho vrátí zpátky. Přispívá k tomu několik věcí:

• Stav světa se hromadí. Odložené předměty, mrtvoly, nařezané klády a trosky se během session sčítají. Něco se uklidí, spousta věcí ne, a každá z nich je něco, co server sleduje.
• Paměť roste. Dlouho běžící servery v Unity mívají tendenci během dnů v paměti stoupat, částečně kvůli výše uvedenému stavu a částečně proto, že spravovaný runtime drží paměť, kterou už použil. Jestli se to počítá jako únik, nebo normální růst, závisí na buildu a mezi patchi se to mění. Článek úniky paměti u herních serverů vysvětluje, jak je rozeznat.
• Garbage collection je dražší. Větší halda znamená delší pauzy při sběru, které se projevují jako krátké, nepravidelné záseky - na rozdíl od záseků při ukládání, které jsou pravidelné.
• AI a fyzika se rozjíždějí. Skupiny nepřátel a simulované objekty, které se nikdy úplně neusadí, spotřebovávají CPU i v oblastech, kde nikdo není.

Řešení je nenápadné: restartuj server podle plánu. Jednou denně v době, kdy nikdo nehraje, je pro většinu skupin správně; velmi aktivní server s osmi hráči může chtít dvakrát. Restart znovu načte svět z posledního uložení, zahodí nahromaděný odpad a vrátí paměť na výchozí úroveň.

Dobrá sekvence restartu:

1. Upozorni hráče, pokud vaše skupina hraje v nepravidelných hodinách. Na serveru není žádný broadcast příkaz, takže to proběhne přes Discord.
2. Nech server čistě zastavit, aby se při vypnutí uložil. Nezabíjej ho.
3. Udělej zálohu uložení, jakmile se zastaví, nebo těsně před restartem.
4. Spusť ho a ověř, že se svět načetl z očekávaného slotu.

Na RE:NODE tohle řeší karta Schedules jako uspořádané úlohy na cron výrazu - záloha, pak restart jako power akce - se zálohami uloženými mimo stroj, který chrání. Úvahy o výběru času a četnosti jsou v článku restart plány, které pomáhají.

Čtení grafů: paměť, nebo CPU#

Než koupíš větší tarif nebo začneš měnit nastavení, zjisti, který zdroj opravdu chybí. Příznaky se liší.

Graf paměti, který během dnů stabilně stoupá a při každém restartu klesne, je normální. Ten, který dosáhne limitu během hodin po restartu, znamená, že svět přerostl tarif. Graf CPU přišpendlený na limitu jen při hraní patří serveru, který potřebuje rychlejší nebo větší podíl, nebo nižší cíl snímků; vysoký graf, když nikdo není online, je problém procesu, ne dimenzování.

Na RE:NODE konzole ukazuje grafy paměti, CPU a disku proti limitům tarifu, což je přesně to srovnání, které chceš. CPU je tvrdě omezeno na podíl, který sis koupil: server na 100 procentech běží pomaleji a nikdy se kvůli tomu nepozastaví. Paměť funguje jinak - na limitu se kontejner zastaví a čistě znovu spustí, místo aby se swapoval - což u této hry znamená ztrátu všeho, co se stalo od posledního uložení. Pokud se to děje, je to nejsilnější signál přejít na vyšší tarif a změna tarifu server nepřestavuje ani se nedotkne světa. Tvary grafů podrobněji probírá článek čtení grafu zátěže serveru a samotné rozhodnutí pokrývá kdy upgradovat tarif.

Řešení problémů s pomalým serverem#

Server laguje, ale graf CPU je daleko od limitu. Dívej se na jedno jádro, ne na součet. Hlavní smyčka může zahlcovat jedno vlákno, zatímco celkové procento vypadá uvolněně. Pokud ano, snížení ActiveTargetFramerate pomůže víc než přidání jader.

Všichni mají rubber-banding ve stejnou chvíli, každých deset minut. To je autosave na velkém světě. Zkontroluj v konzoli řádek o uložení v okamžiku, kdy k tomu dojde.

Laguje jeden hráč a nikdo jiný. To je jeho připojení nebo jeho počítač, ne server. Problém serveru postihuje všechny na stejném místě ve stejnou dobu. Článek latence, jitter a ztráta paketů jim pomůže zjistit, který z nich to je.

Připojování trvá několik minut a server sekne, když se někdo připojuje. Připojující se hráč stahuje stav světa přes port BlobSync. Na vyspělém světě je to velký přenos a stojí to server práci, dokud probíhá. Je to normální a čím větší základna, tím je to horší.

Paměť dosáhne limitu a server se restartuje s návratem světa zpět. Svět potřebuje víc paměti, než tarif má, nebo server běží příliš dlouho. Nejdřív přidej denní restart; pokud i tak dosáhne limitu během dne, přejdi na vyšší tarif. Další příčiny neplánovaných restartů pokrývá článek proč se ti herní server pořád restartuje.

Změna cíle snímků nic nezměnila. Zkontroluj pravopis klíče a že je soubor platný JSON. Chybně napsaný klíč se tiše ignoruje a rozbitý soubor způsobí, že server nastartuje s výchozími hodnotami. Spusť s -verboseLogging, abys viděl, co se načetlo.

Server zpomalil hned po aktualizaci hry. Buď je těžší samotná aktualizace, což se stává a nedá se to nastavením obejít, nebo na Linuxu zaostal build Wine. Než na své straně cokoli změníš, porovnej zkušenosti s ostatními majiteli serverů.

FAQ#

Stačí 8 GB na server Sons of the Forest?

Pro dva až čtyři hráče na světě, který není obrovský, ano. Je to minimum, ne pohodlná rezerva, a dlouho žitý svět s velkou základnou ho přeroste. Sleduj paměť po týdnu hraní, ne hned první večer.

Škodí snížení ActiveTargetFramerate hratelnosti?

Trochu, výměnou za stabilitu. Při 30 se pohyb nepřátel a fyzika aktualizují méně často, čehož si někteří hráči v boji zblízka všimnou. Na serveru, který stejně neudrží 60, působí stabilních 30 obvykle líp než nestabilních 60. Zkus to jednu session, než se rozhodneš.

Proč můj prázdný server skoro nevyužívá CPU?

Kvůli IdleTargetFramerate. Když není nikdo připojen, server běží na pěti průchodech smyčkou za sekundu a při IdleDayCycleSpeed nastaveném na nulu je světový čas zamrzlý. Je to záměr a není důvod to měnit.

Zpomaluje běh pod Wine server?

Jen mírně. Kód hry běží nativně; Wine přidává pár set megabajtů paměti a trochu režie při práci náročné na soubory, jako je ukládání. Lag na serveru hostovaném pod Wine je skoro vždy vlastní zátěž hry, ne překladová vrstva.

Jak často restartovat server Sons of the Forest?

Jednou denně v klidné hodině vyhovuje většině skupin. Vytížený server s osmi hráči může mít prospěch ze dvou restartů denně. Vždy ho nech čistě zastavit, aby se uložil, a k restartu udělej zálohu.

Zrychlí server víc jader CPU?

Nad dvě nebo tři jen zřídka. Simulace se opírá o jedno hlavní vlákno, takže rychlost toho jádra záleží víc než jejich počet. Další jádra pomáhají s ukládáním a s připojováním hráčů, ne s hlavní smyčkou.