Jak mi GitLab rozbil VPS

Není překvapením, že lidé nemají rádi, když se něco rozbije. Od rozbitých smartphonů po nefunkční spotřebiče, frustrace je téměř univerzální a zcela pochopitelná.

Já nejsem výjimkou. Nejenže nemám rád, když se něco rozbije, ale také nemám rád, když to nefunguje správně vždy a stoprocentně. Náhodné záseky a náhlé bílé obrazovky jsou nejhorší.

A přesně to se začalo dít s mým soukromým serverem, který hostuje tento web a několik mých osobních projektů a dalších webů. Je to trochu složitější, protože jeho účel byl několikrát změněn, ale své nynější úkoly by zvládnout měl v pohodě.

Jenže nezvládal.

Nedávno jsem vytvořil jednoduchou SPA prezentaci v Reactu, která cykluje náhodné citáty mých kolegů, parodující oblíbené motivační kartičky. Místo „Nikdy se nevzdávej“ ukazuje „Nesnáším C++“ a tak podobně, s krásnými obrázky na pozadí, aby absurdnost byla ještě větší. Byla to celonoční práce (mám i JSONovou databázi a administrátorské rozhraní udělané pomocí react-admin na přidávání nových citátů), ale všem se to líbí, takže to za to stálo. Máme to teď neustále puštěné v kanceláři na jedné ze zavěšených obrazovek.

Ale jednoho dne to přestalo fungovat. Jen na minutu nebo tak, nic vážného. Asi problém sítě?

Pak se to začalo stávat častěji, někdy i několikrát za den. Snažil jsem se to vyřešit, ale nemohl jsem přijít na to, co se děje. Je to jen jednoduchá stránka, která dělá požadavek a ukazuje nějaký text, ale celá stránka selhávala, nejen samotný fetch request.

Myslel jsem si, že by to mohl být problém s PM2 službou nebo Apachem při servování aplikace. Prohlédl jsem si logy, ale nic jsem nenašel, kromě toho, že Node si stěžoval na některé zastaralé knihovny.

Na chvíli jsem to vzdal, dokud se to nestalo znovu, když jsem byl v kanceláři. Jeden kolega mě informoval, že to zase nefunguje, takže jsem se okamžitě pokusil připojit k serveru přes SSH, abych zjistil, co se děje.

Ale nemohl jsem se připojit. Nejprve jsem si myslel, že je to jen problém sítě, ale všechno ostatní fungovalo. Takže možná měl poskytovatel VPS nějaké problémy s připojením?

V posledním pokusu zjistit, co se děje, jsem se podíval do OpenNebula administrace VPS, abych zjistil, jestli je virtuální stroj vůbec zapnutý. Vypadalo to v pořádku, ale když jsem se připojil přes vestavěné VNC v administraci, přivítal mě tento krásný obrázek v paměťovém bufferu:

Jo, došla paměť. To je důvod, proč celý server nereagoval. Něco mi žralo paměť jako Santa Claus cukroví na Vánoce, až musel zasáhnout OOM killer a eliminovat Santu.

Alespoň jsem teď věděl, co se děje, a měl jsem i viníka: službu zvanou gitlab-runsvdir. Je to služba GitLabu založená na runit (UNIXové init schema s dohledem nad službami), která zajišťuje, že ostatní služby běží a automaticky je restartuje, pokud spadnou. Také spravuje adresář služeb (jako konfigurační soubory) a dělá další věci, ale nejsem odborník, takže nebudu předstírat, že vím všechno, co dělá.

Pointa je, že na tuto službu by člověk neměl sahat. Existuje jiný proces gitlab-ctl pro front-end a obvykle, když chcete GitLab spustit, zastavit nebo restartovat, používáte ten. Služba gitlab-runsvdir se zřejmě spouští při startu a měla by být ponechána na pokoji.

Upřímně, ani nevím, proč jsem si zvolil GitLab jako svou soukromou DevOps platformu. Chtěl jsem jen něco, kam bych mohl pushovat své osobní projekty, a ani nepoužívám 99% nástrojů, které GitLab poskytuje. Ale v práci používáme GitLab, takže jsem si ho automaticky nainstaloval na svůj VPS bez zvážení alternativ. To byla chyba, protože můj VPS sotva splňuje minimální požadavky (čti: nesplňuje).

Přijde mi to ale šílené, protože jsem na svém VPS bez problémů provozoval doslova celý soukromý server pro World of Warcraft, ale pro GitLab to nestačí?

No to je jedno, provedl jsem nějaké změny.

• Zakázal jsem clusterový režim, aby aplikaci obsluhoval pouze jeden proces Puma. Nepotřebuji žádné souběžné připojení; jsem doslova jediný uživatel.
• Snížil jsem režim souběžnosti daemonu, co běží na pozadí. Je teď pravděpodobně pomalejší, ale nealokuje tolik paměti. Nepotřebuji bleskovou rychlost.
• Snížil jsem některé limity paměti a souběžnosti služby úložiště.
• Zakázal jsem monitorovací službu. Nepotřebuji monitorovat sám sebe.
• Snížil jsem velikost paměťových bloků, které GitLab předem alokuje pro zlepšení výkonu. Opět, mohu počkat pár milisekund navíc.

Vlastně jsem se víceméně řídil těmito doporučeními: Running GitLab in a memory-constrained environment.

Zatím to vypadá dobře, uběhlo několik dní bez jediného pádu. Musím ale přiznat, že i po změnách je GitLab stále obrovský žrout zdrojů. Asi čtvrtina mé paměti je neustále používána a dalších 20% je alokováno a dealokováno periodicky:

Možná bych měl přejít na Gitea, Forgejo nebo něco jiného. Ale jsem docela líný a už mám rozchozený GitLab, takže prozatím zůstane. Uvidím, jak to bude v budoucnu.