„Server prostě spadne při startu" je nejčastější stížnost modovaného Minecraftu na jakémkoli fóru a obvyklé odpovědi jsou hádání: přidej RAM, přeinstaluj, zkus jiný balík. Chtěli jsme skutečná data, a tak jsme 100 nejpopulárnějších CurseForge modpacků spustili na vlastním hardwaru. Každý balík, který selhal, dostal druhý nezávislý pokus a selhání se počítalo, jen když se zopakovalo. Právě tohle pravidlo bylo důležité: šest balíků, které při prvním pokusu vypadaly rozbitě, napodruhé naběhlo bez potíží, mimo jiné All the Mods 10.
Hlavní výsledek: dnes ze 100 nejpopulárnějších modpacků naběhne 74. Když jsme s testováním začínali, bylo jich 46, šest bylo hod mincí a 48 selhalo v obou pokusech. A teď ta nepříjemná část: když jsme těch 48 selhání dohledali ke kořenovým příčinám, většina z nich byla naše chyba, ne chyba balíků. Číslo posunula oprava naší vlastní pipeline. Nalezené příčiny nejsou specifické pro nás, a právě proto stojí za zveřejnění: modpackové servery padají ze stejných důvodů všude.
Největší zjištění: většina balíků běží na hraně paměti
Ještě před taxonomií selhání jedno číslo, které změnilo náš pohled na modovaný hosting. Z 94 balíků, které nám daly použitelné měření, jich 43 běželo s rezervou paměti 5 % nebo menší. Většina těch hodnot je v klidu, na čerstvě vygenerovaném světě a s nulou připojených hráčů. Deset ze čtyřiceti tří je okamžik, kdy pack narazil na svůj strop a skončil. Osmnáct z nich hlásilo 0 %, tedy s každým megabajtem svého limitu obsazeným ve chvíli, kdy dokončily start. Všechna naměřená data zveřejňujeme pack po packu.
Tím se vysvětluje nejotravnější symptom modovaného Minecraftu: server, který včera fungoval a dnes padá. Balík, který v klidu drží 99 % svého limitu paměti, žádný stabilní stav nemá. O tom, jestli přežije start, rozhoduje načasování garbage collectoru. Přidej jednoho hráče, jeden nápor generování chunků, jednu rušnou mobí farmu, a stejný server, který pětkrát v řadě naběhl, zabije pošesté OOM killer. Pokud ti modovaný server padá jen občas, měla by být rezerva paměti tvůj první podezřelý, ne poslední.
Taxonomie selhání
Tohle opakovaná selhání skutečně zabíjelo, zhruba sestupně podle četnosti.
Klientské módy na serveru. Modpacky se vydávají ve dvou podobách: klientský balík, který si instalují hráči, a server pack, jejž autor připraví bez klientských módů. Když server pack chybí nebo se ignoruje, přistanou klientské módy na serveru a loader při startu spadne. Zákeřnější varianta: některé starší balíky vydávají server pack, který nástroje tiše nerozpoznají, takže instalátor bez upozornění sáhne po klientských souborech. Když crash log jmenuje mód a ten mód je minimapa, shader nebo cokoli kosmetického, máš příčinu.
Špatný build loaderu. Balík je postavený na konkrétní build Forge, Fabricu nebo NeoForge. Nainstaluj ho na „nejnovější" a balíky nabité mixiny umírají způsobem, který vypadá jako náhodné chyby módů. Oprava, ke které jsme došli, se dá zkopírovat kdekoli: vlastní manifest.json balíku říká loader, jeho přesný build i verzi Minecraftu. Věř manifestu, ne stránce s výpisem, a rozhodně ne „nejnovějšímu".
Špatná verze Minecraftu. Štítky v katalozích modpackových webů jsou hrubší než manifest a občas prostě špatně. Čtyři balíky v našem průchodu selhaly, protože verze naznačená výpisem nebyla ta, na kterou byl balík postavený. Stejná oprava: pravdu má manifest.
„Server packy", které jsou ve skutečnosti instalátory. Sedm balíků dodalo „server pack", ve kterém žádný server nebyl, jen instalační skript určený ke spuštění rukou. Nahraný na hosting, který čeká připravené soubory, nenainstaluje nic a server hned skončí. Když ti server „naběhne" a do vteřiny umře s téměř prázdným logem, podívej se, co v tom zipu balíku vlastně je.
Obyčejný nedostatek paměti. Osm balíků nedokázalo naběhnout na RAM, která je pro ně doporučená; jednu 468módovou příšeru zabil OOM killer při víc než 2 GB rozbalených serverových souborů. Dvě pasti z naší vlastní analýzy logů: exit code 137 je kernel zabíjející proces kvůli paměti, ne chyba módu, a dva takové případy jsme zpočátku mylně zařadili mezi problémy módů. A děsivě vypadající řádek invalid dist DEDICATED_SERVER se objevuje i na naprosto zdravých serverech, takže ho neřeš.
Selhání stahování a balení. Zbytek: balíky, jejichž soubory se nepodařilo vůbec stáhnout, a špatně označené uploady, kde byl „serverový" soubor klientský zip. Nudné příčiny, skutečná selhání.
Co s tím, když ti server padá
Praktický seznam v pořadí, platný na jakémkoli hostingu:
- Podívej se, jak proces skončil. Zabitý s exit 137 nebo s OOM řádkem? Je to paměť. Zvyš limit nebo balík ořež, nic jiného nepomůže.
- Přečti si první jmenovaný mód v crashi. Kosmetický nebo klientský? Běží ti klientské soubory, sežeň server pack od autora.
- Ověř loader a verzi proti souboru
manifest.jsonbalíku, ne proti výpisu na webu. Přesný build, ne nejnovější. - Koukni dovnitř serverového zipu. Pokud je uvnitř instalační skript, spusť ho lokálně nebo najdi hosting, který takový tvar zvládne.
- Teprve pak podezírej samotný balík. V našich datech byly opravdu rozbité balíky malá menšina.
Jak se crash log opravdu čte
Taxonomie výše říká, co se pokazí. Tady je pořadí, ve kterém to ověřovat, a to pořadí je důležitější než samotný seznam. Několik těchto selhání se totiž navzájem vydává jedno za druhé. Je to stejné pořadí, jaké používá náš vlastní klasifikátor u každého spadlého kontejneru.
1. Zabil ho někdo zvenku? exit 137. To není mod ani stack trace, ale OOM killer jádra, který kontejner zastavil. Log proto často končí uprostřed věty a bez čehokoli, co by vypadalo jako chyba. Všechno nad tím je jen projev, ne příčina.
2. unable to create native thread není problém s pamětí. Přijde jako java.lang.OutOfMemoryError, a přesně proto se čte špatně. JVM nedokázala vytvořit vlákno, což je strop na procesy nebo PID, ne halda. Spustí se i na stroji, kde jsou gigabajty volné. Tohle je potřeba kontrolovat ještě před vzory pro haldu, protože holý java.lang.OutOfMemoryError na konci řádku sedne i na ně.
Sami jsme to měli špatně a cena byla hodně konkrétní: panel lidem řekl, ať si koupí větší plán, oni si ho koupili a limit, do kterého opravdu naráželi, se nepohnul.
3. Až teď skutečná paměťová selhání. OutOfMemoryError: Java heap space znamená, že větší halda opravdu pomůže. OutOfMemoryError: Metaspace je o metadatech tříd, ne o datech světa, a velké packy do něj naráží i s naprosto zdravou haldou. GC overhead limit exceeded říká, že Java strávila skoro veškerý čas úklidem paměti a vzdala to, což je táž tíseň v jiném kabátě.
4. Verze Javy ještě před čímkoli, co vypadá na mody. Unsupported class file major version a hlášky typu „requires Java 17“ řeší verze Javy. Žádné odebírání modů s tím nepohne.
5. ClassNotFoundException není vždy mod. Pokud má server vlastní argumenty JVM, začni u nich. Neuzavřená mezera v hodnotě -D rozdělí argument, zbylý token se vezme jako hlavní třída a výsledná chyba vypadá přesně jako selhaný mod. Poslat někoho hrabat se v mods/ kvůli překlepu v nastavení je špatně hned dvakrát, a na serveru bez jediného modu dokonce třikrát.
6. Teď už můžeš obviňovat mod. ModLoadingException, „missing or unsupported mandatory dependencies“, „loading errors have occurred“. V téhle fázi bývá jméno ve výpisu opravdu ten viník.
7. Address already in use znamená, že port drží něco jiného. Skoro vždy předchozí proces, který ještě nestihl skončit.
Jeden řádek, který nikdy není příčinou
Forge píše invalid dist DEDICATED_SERVER i na naprosto zdravých serverech. Vypadá to jako chyba, objeví se to hned na začátku logu a neznamená to nic. Během tohohle testování jsme to dvakrát zapsali jako příčinu, než jsme to ověřili proti serverům, které běžely úplně v pořádku. Pokud v logu hledáš první znepokojivý řetězec, tohle je ten, který ti sežre odpoledne.
Poctivý závěr
Do průchodu jsme šli s tím, že sepíšeme katalog rozbitých modpacků, a sepsali jsme hlavně katalog vlastních chyb. Třicet osm ze 48 opakovaných selhání vedlo na stranu hostingu: špatně zvolená cesta instalace, nepřipnutý build loaderu, verze převzatá ze štítků místo z manifestu, příliš tenká doporučení RAM. Balíky zveřejňují všechno, co je ke správnému startu potřeba. Selhání vznikla tím, že to nikdo nečetl.
Z toho plyne i vodítko pro výběr hostingu na modpack: zeptej se, jak vybírají serverové soubory, jestli připínají build loaderu z manifestu a kolik RAM doporučují pro tvůj konkrétní balík. A hlavně, jestli to číslo pochází z měření, nebo z odhadu. Naše měření u jednotlivých balíků dnes pohánějí doporučení RAM na stránkách modpacků a pozadí kolem dimenzování najdeš v článku kolik RAM potřebuje Minecraft server.
Modpackový server, který nechce naběhnout, skoro nikdy není záhada. Je to jedna ze šesti příčin a pět z nich zkontroluješ do deseti minut s crash logem a manifestem balíku před sebou.