CPU, nebo RAM: co omezuje herní server

Hosting se prodává podle paměti, protože paměť se snadno spočítá. Většinu herních serverů ale omezuje to, jak rychle dokáže jedno jádro CPU dokončit krok simulace, což se špatně počítá a ještě hůř inzeruje. Kvůli tomu nesouladu přidání gigabajtů zasekávajícímu se serveru tak často nezmění vůbec nic a upgrade, který problém opravdu vyřeší, je někdy levnější než ten, který ne. Hráčům oba problémy připadají stejné, ale v číslech nemají nic společného, takže celé umění spočívá ve vědomí, na která čísla se dívat. Když víš, kde jsou, zabere to asi třicet sekund.

Co každý z nich ve skutečnosti dělá#

Paměť drží stav. Načtený svět, entity v něm, cache chunků, data pluginů, haldu JVM. Paměť rozhoduje o tom, kolik toho může existovat najednou. Má tvrdou hranu: pod čárou je všechno v pořádku, nad ní je proces zabit. Na kontejneru s limitem neexistuje „trochu málo paměti“ - jsi pod limitem, nebo jsi mrtvý.

CPU koná práci. V každém ticku server posune simulaci a téměř každý herní engine to dělá na jednom vlákně. CPU rozhoduje o tom, jak rychle ten krok skončí. Má měkkou hranu: s blížícím se limitem ticky trvají déle, svět zpomaluje a nic nespadne. Degraduje místo selhání, a právě proto zůstává měsíce nediagnostikované.

Existuje třetí zdroj, který se obvykle zařazuje k jednomu z těchto dvou chybně. Disk se projevuje krátkým zamrznutím podle plánu - uložení světa, záloha, rotace logů - a lidé to hlásí jako lag a kupují CPU. A čtvrtý, síť, která se projeví tak, že jeden hráč má špatný zážitek, zatímco ostatní jsou v pořádku.

Ještě jedno rozlišení, které na každém hostingu s panelem záleží. Údaj o CPU v tarifu je procento jednoho jádra: 100 je jedno jádro, 250 jsou dvě a půl. Je to omezení, ne rezervace a není to záruka toho, která fyzická jádra dostaneš. Na RE:NODE je to tvrdý limit - tvůj kontejner nikdy nesmí přes něj - a server na 100 % je pomalý, ne rozbitý, a nikdy se za to nepozastavuje. Pro diagnostiku to znamená: server přilepený na svém limitu CPU se nechová špatně, říká ti, že limit je limit.

Jak je rozlišit za třicet sekund#

Dva řádky, které si lidé pletou, jsou druhý a čtvrtý. Server, který se restartuje s prázdným logem, je téměř vždy zabíjen kvůli paměti - proces nedostane příležitost napsat poslední vzkaz. A server, jehož graf paměti je plochý a pohodlný, zatímco si hráči stěžují, je problém CPU, ať je větší tarif jakkoli lákavý.

Jak správně číst paměť#

Nejčastější chybou je zaměňovat paměť, o které si hra myslí, že ji má, za paměť, kterou jí kontejner dává.

Na serveru v Javě se halda JVM nastavuje přes -Xmx a halda není celý proces. Metaspace, zásobníky vláken, přímé bytové buffery, cache kódu JIT a vlastní struktury garbage collectoru žijí mimo ni. Nastav -Xmx4G uvnitř kontejneru o 4 GB a proces překročí 4 GB a bude zabit, s ničím v herním logu, protože hře paměť nedošla - došla kontejneru.

# Leave the JVM headroom. On a 6 GB plan:$ java -Xms5G -Xmx5G -XX:+UseG1GC -XX:+ParallelRefProcEnabled \    -XX:MaxGCPauseMillis=200 -XX:+AlwaysPreTouch -XX:+DisableExplicitGC \    -jar paper.jar nogui

Rozumné pravidlo je -Xmx na 80-85 % limitu kontejneru, s alespoň 512 MB navíc a celým gigabajtem u čehokoli s mody. Nastavení -Xms rovného -Xmx s -XX:+AlwaysPreTouch znamená, že halda se zabere předem, takže graf paměti vypadá od první minuty alarmujícím dojmem a plochý - to je správně a záměrné, ne únik. Přepínače JVM pro Minecraft a verze Javy probírají zbytek přepínačů a limity paměti pro Node vysvětleny pokrývají ekvivalentní problém pro aplikace v Node, které mají vlastní oddělený strop haldy.

Na stroji, který ovládáš, jsou důkazy na třech místech:

$ free -h                                  # what the system has left$ dmesg -T | grep -i "killed process"      # the kernel's own record of a kill$ journalctl -k | grep -i oom              # same, on a systemd box# With cgroup v2, which is what a container limit actually is:$ cat /sys/fs/cgroup/memory.max            # the limit, in bytes$ cat /sys/fs/cgroup/memory.current        # what is in use right now$ cat /sys/fs/cgroup/memory.events         # oom_kill counts, cumulative

memory.events je ten, který je třeba znát. Pokud je oom_kill větší než nula, něco v tomto kontejneru bylo zabito kvůli paměti a místo teorie máš fakt. Swap v Linuxu a OOM killer je dlouhá verze.

Tvar grafu paměti ti napoví, o jaký druh problému s pamětí jde:

• Stoupne a pak je plochý, hluboko pod limitem. Zdravé. Takhle vypadá správně dimenzovaný server.
• Stoupne k limitu a zůstane přilepený. Buď halda, které bylo řečeno, ať zabere všechno, nebo skutečný nedostatek. Zkontroluj, zda jsou špatné i časy ticku; přilepený graf s dobrými časy ticku je obvykle jen -Xms.
• Pila, hluboká a častá. Garbage collection pracuje naplno, protože halda je pro pracovní sadu příliš malá. To stojí CPU a projeví se jako špičkové časy ticku.
• Pomalu stoupá celé dny a nikdy neklesne. Únik, nebo svět, který skutečně stále roste. Týdenní restart to zamaskuje; profiler to najde.

Jak správně číst CPU#

Číslo, na které se dívat, není „využití CPU“. Je to využití CPU vlákna, na kterém záleží, vůči limitu, který sis koupil.

$ top -H -p $(pgrep -f paper.jar)   # per-thread, not per-process$ uptime                            # load average over 1, 5, 15 minutes$ vmstat 1 5                        # r = runnable, st = stolen by the hypervisor# cgroup v2 again - this is the one that proves throttling:$ cat /sys/fs/cgroup/cpu.max        # quota and period, e.g. "250000 100000"$ cat /sys/fs/cgroup/cpu.stat       # nr_throttled, throttled_usec

Rostoucí nr_throttled, zatímco server působí špatně, je průkazné: tvůj kontejner je opakovaně zastavován na své kvótě, uprostřed ticku. Tak vypadá limit CPU zevnitř a žádná změna konfigurace uvnitř hry ho neodstraní.

Tři věci tady lidi mate:

Přidělení čtyř jader s využitím 25 % může být pořád omezené CPU. Pokud je jedno vlákno přilepené na 100 % jednoho jádra a tři jádra stojí, pohled na úrovni procesu ukáže 25 %. top -H ukáže pravdu. Tohle je běžný stav vytíženého herního serveru, protože simulace je jedno vlákno.

Čas steal není tvoje CPU. Sloupec st ve vmstat je čas, kdy tvoje virtuální CPU chtělo běžet a hypervizor ho dal někomu jinému. Trvale nenulový steal znamená, že hostitel je přeprodán, a žádné ladění z tvé strany nepomůže. Sdílené CPU a hluční sousedé popisují, co s tím lze dělat.

Load average není procento. Load 4,0 na čtyřjádrovém stroji je plné vytížení; tytéž 4,0 na jednojádrovém kontejneru znamená, že tři věci trvale čekají. Čti to vůči svému přidělení.

Než zaplatíš za jádra, stojí za to vědět, které hry opravdu využijí víc než jedno:

Vzorec: druhé jádro stojí za koupi, osmé obvykle ne a vyšší takt stojí víc než obojí. Fork Folia od Paper je pozoruhodnou výjimkou v Minecraftu - rozděluje svět na nezávisle tikající oblasti a škáluje přes jádra - ale potřebuje pluginy napsané pro něj, takže je to volba na začátku projektu, ne oprava aplikovaná na zápasící server.

Co dělat, když je to paměť#

1. Nejdřív zkontroluj `-Xmx` proti limitu kontejneru. Víc tarifů je zabíjeno chybně nastavenou haldou než skutečným nedostatkem. Oprava je zdarma.
2. Sniž to, co je načtené. Snižuj view-distance a simulation-distance, zmenši hranici světa, předgeneruj místo generování za běhu, vyčisti nahromaděné entity. Každý chunk, který nedržíš, je paměť, kterou nepotřebuješ.
3. Najdi únik, než ho začneš krmit. Paměť, která navždy stoupá, je plugin nebo mod. Profiler ho pojmenuje za minuty; větší tarif jen posune termín.
4. Pak, a teprve pak, kup paměť. Je to jediný problém, který větší tarif skutečně vyřeší, čistě a trvale.

Problémy s pamětí jsou v jistém smyslu ten dobrý druh: mají jasnou příčinu, jasnou opravu a oprava se škáluje s penězi. Kolik RAM potřebuje server Minecraft a kolik hráčů se vejde na server obě procházejí dimenzování.

Co dělat, když je to CPU#

Pořadí je tu jiné, protože nejlevnější oprava téměř nikdy není hardware.

1. Najdi to drahé. Většina serverů omezených CPU má jednu příčinu, ne obecný nedostatek: farmu mobů, plugin tikající každý herní tick, řetěz hopperů, skript spouštějící databázový dotaz přímo v běhu. Než uděláš cokoli jiného, profiluj - profiler spark pro Minecraft, jinak ekvivalent ve tvé hře.
2. Dělej za tick méně práce. Sniž vzdálenost simulace, omez počty entit, prodluž interval všeho naplánovaného, odstraň pluginy, které nepoužíváš. Tady žijí velká vítězství.
3. Přesuň blokující práci z hlavního vlákna. Synchronní zápis na disk nebo databázové volání v běhu spotřebovává rozpočet ticku tím, že nic nedělá. Asynchronní ukládání a sdružená spojení jsou konfigurace, ne hardware.
4. Kup takt, ne jádra. Pokud jsou kroky jedna až tři vyčerpané, zbývající páka je rychlejší jádro. To obvykle znamená jiný stroj, ne větší přidělení na tomtéž - u dedikovaných strojů je model CPU skutečně uveden, což je jediný způsob, jak před koupí porovnat takt.
5. Smiř se s nižším počtem hráčů. Nepopulární, poctivé a někdy správné.

Obecný princip: problémy s pamětí se řeší koupí dalších, problémy s CPU tím, že děláš méně. Server omezený CPU, který dostane větší tarif se stejnou generací procesorů, získá o málo vyšší strop a stejný problém o měsíc později.

Praktický příklad#

Server Paper na tarifu 4 GB, 2 vCPU. Dvacet stálých hráčů, rok starý svět, každý večer stížnosti na „lag“.

/mspt   -> 48.6/312.4, 44.1/312.4, 29.8/486.0memory  -> pinned at 3.9 GB of 4 GB all dayCPU     -> 185% of an allowed 200%, all evening

Čti ty tři řádky společně. Graf paměti je přilepený, což vypadá jako odpověď - ale halda byla nastavena přes -Xms3G -Xmx3G, takže samozřejmě je přilepený, a žádné události OOM nejsou. CPU je na 92 % svého přidělení a dělá to všechno jedno vlákno. Průměrný čas ticku je na hraně rozpočtu 50 ms a maximum je téměř desetkrát větší.

Diagnóza je CPU, s problémem špiček navrch. Maximum 486 ms je odlišný problém od průměru 29,8 ms: něco občas trvá půl sekundy, a to bývá generování chunků na hranici světa nebo automatické ukládání. Profiler našel skutečné viníky asi za deset minut: view-distance=12 na serveru, kde se nikdo nedívá dál než na šest, a 3 000 nahromaděných entit předmětů v jedné základně.

Oprava nestála nic. view-distance=8, simulation-distance=6, časovač mizení předmětů a průměrný čas ticku klesl na 18 ms. Tarif 4 GB nikdy nebyl problém. Kdyby majitel koupil 8 GB, graf by vypadal zdravěji a server by působil úplně stejně.

Koupit správnou věc#

Před jakýmkoli nákupem získej dva datové body s týdenním odstupem stejným měřením. Čtení grafu zátěže serveru popisuje, na co se díváš, kdy upgradovat tarif popisuje prahy, které to ospravedlňují, a co NVMe doopravdy mění pokrývá třetí zdroj, který se svádí na první dva. Pokud vyjde odpověď „celý stroj“, kompromis popisuje volba mezi VDS a herním panelem.

FAQ#

Zrychlí můj server víc RAM?

Jen pokud mu chyběla paměť. Na serveru, jehož graf paměti je plochý a časy ticku špatné, víc paměti nezmění nic měřitelného. Paměť zvyšuje strop toho, kolik může existovat; nezrychluje aktualizaci toho, co existuje.

Co ve skutečnosti znamená 2 vCPU?

Dvě stě procent jednoho jádra jako omezení. Neznamená to dvě jádra rezervovaná pro tebe, a protože většina herních serverů simuluje na jednom vlákně, jediné vlákno může stále využít jen 100 % tohoto přidělení. Druhé jádro pokrývá síť, ukládání, garbage collection a vše ostatní kolem simulace.

Proč můj server pořád používá 100 % CPU?

Protože něco stále žádá o práci a limit dělá svou práci. Na RE:NODE je server na 100 % pomalý, ne v nesnázích, a nikdy se za to nepozastavuje. Správná otázka je, zda je čas ticku v rozpočtu; pokud je, vysoké CPU je jen efektivní server.

Hoster říká 8 GB, ale Minecraft vidí jen 6. Proč?

Protože -Xmx bylo záměrně nastaveno pod limit kontejneru. JVM potřebuje paměť mimo haldu pro vlákna, metaspace a buffery a halda nastavená na plnou velikost kontejneru způsobí zabití procesu. 6 GB haldy v kontejneru o 8 GB je správně.

Je pád bez chybové zprávy vždy paměť?

Ne vždy, ale takhle se sází. Proces zabitý jádrem za překročení limitu paměti nemá příležitost cokoli zalogovat. Než předpokládáš chybu, zkontroluj čítač OOM nebo log jádra. Ostatní příčiny probírá proč se váš herní server pořád restartuje.

Mám koupit víc jader, nebo rychlejší jádro?

Rychlejší jádro, pro téměř každou hru. Simulace běží na jednom vlákně, takže strop určuje takt a další jádra pomáhají jen s prací kolem. Dvě rychlá jádra porazí osm pomalých pro herní server a pro databázi nebo build server platí opak.