Výpadky GitLabu 01/2022 #67
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
@Podhorecky: Nejsem z toho moudrý (a neočekávám ani, že vy budete), takže tu jen víceméně sesumarizuji co vím s nějakými svými poznámkami a anotacemi.
tl;dr je, že ten systém operuje na hranici svých možností a pomohlo by mu se nějakého workloadu zbavit. Největšími žrouty paměti jsou (v tomto pořadí): GitLab, ClamAV (antivirus používaný mailovým systémem, ale na ten možná budu schopen něco vymyslet), Decidim, Odoo.
Analýza
GitLab chcípne s chybou 502, protože se zakousnou některé jeho procesy. Dochází k tomu někde v jádru systému a když se to stane, produkuje to ve
/var/log/kern.log
a v sériové konzoli logy podobné následujícímVýpisy z logů
Ve výpisu jsou zmíněny procesy, resp. vlákna
bundle
,thread_pool.rb
ascheduler.rb
. Všechny by měly být spouštěny webovým serverem Puma, který je psaný v Ruby (proto ta vlákna s *.rb na konci), který GitLab používá. Ve výpisu stromu procesů jsou vidět zombie procesybundle
, nicméně ta zombifikace bude nejspíše symptom, nikoliv příčina.Dále jsou ve výpisu procesů také vidět různé procesy čekající na diskové I/O, které s výše uvedenými nemusí vždy souviset. Zdá se, že jde o procesy, které prováděly diskové operace ve chvíli kdy ke kernel bugu došlo. Při minulém incidentu mezi nimi byl například i postgres nebo procesy Onlyoffice běžící v odděleném kontejneru. Teď vidím ssh daemona GitLabu. Při obou incidentech byl ve výpisu zachycen i proces pro vytváření záloh WordPressu, rep. jejich kompresi (nutno podotknout, že
tar
v tomto případě data z disku pouze čte a předává je rourougzip
procesu, který je komprimuje a zapisuje zpět na disk. Viset ale zůstaltar
. Vzhledem k neobvyklosti problému to ale nemusí nic znamenat).A taktéž je ve výpisu vidět podproces jádra pro zkompaktnění paměťových stránek (článek s popisem), který čeká na I/O.
Výpisy stromů procesů
Poslední jmenovaný je vzhledem k vytížení systému hlavním podezřelým. Systém většinu času operuje na hranici svých možností, co se zaplnění RAM a swapu týče, a kernel bugy naznačují, že k problému dochází právě při pokusu o přístup či uvolnění paměti.
Pokusy o zmírnění dopadu
1) Ve stávající situaci byl SSH port GitLabu otevřen pro přístup do celého světa, během čehož byl bombardován pokusy o přístup s neplatnými údaji, které byly odmítány a při opakování promptně zaříznuty fail2banem. Omezil jsem přístup pouze na rozsahy IP adres používané ISP v Česku. Kdyby se někdy outsourcovaly nějaké věci kolem kódu v GitLabu do Indie nebo na jiné Slovensko, bude potřeba ta omezení upravit.
Nečekám že by tato akce měla jakýkoliv dopad na vytížení, protože SSH daemon je oproti některým ostatním službám běžícím na server naprosto titěrný, ale není důvod to neudělat. Obzvlášť když byl SSH daemon při jednom z incidentů postižen.
2) ClamAV po startu drží celou databázi antivirových vzorků v paměti, aby s nimi mohl bleskurychle pracovat a nepotřeboval dodatečné přístupy na disk. Databáze obsahuje cca 8,7 milionu vzorků a rozbalená a zaindexovaná zabírá cca 1 GB v paměti RAM. Vzhledem k tomu, že používáme i virové databáze třetích stran, včetně takových které reagují na nové hrozby dynamicky, je pro maximální možnou ochranu potřeba jejich databáze obnovovat v řádu minut. Při obnovení databáze dochází k jejímu nahrání do paměti zatímco předchozí verze v paměti stále existuje a pracuje se s ní. Každých 5 minut (interval obnovy) tedy využití RAM ClamAV špičkově vyskočí na dvojnásobek a drží se tam po dobu cca 30 sekund, dokud se obnovená nová databáze nenačte a stará kopie nezahodí, čímž dojde k uvolnění paměti.
Nastavil jsem tedy v tuto chvíli
ConcurrentDatabaseReload no
v/etc/clamav/clamd.conf
, což způsobí, že ClamAV nebude uchovávat kopii databáze v paměti během obnovy, ale místo toho nejprve starou databázi zahodí a pak teprve načte novou. To by mělo poměrně značně snížit fluktuace využité paměti, za cenu toho, že doručení některých mailů může být zdrženo v řádu jednotek minut.Trvalé řešení, které nejprve musím navrhnout a otestovat, je mít dvě souběžné instance ClamAV. Jednu s hlavní databází, která se obnovuje pouze jednou za den, a druhou instanci s tou "online" databází, která je podstatně menší a může se tak obnovovat častěji a rychleji než v současnosti.
wow... mno pěkné.
jen pro info, z mé činnosti mohlo před časem přistát na NextCloud několik desítek, možná stovek MB souborů, ale to snad nebylo mnoho. Také jsem před pár dny updatoval novou verzi OnlyOffice, to bylo pak vidět, že při prvním spuštění dokumentu mu chvilku trvalo, než si to znova OO natahal do paměti. Nadále NC a OO běží vpořádku.
Nedávno jsem také updatoval pluginy a šablony ve WordPressu, protože přišla nová verze WP... ovšem samotný WP jsem ještě neupdatoval. A nespěchám na to.
Kdybyste vyhodnotil že by prospělo odmazat uživatelská data, tak něco smažu, kdyby to měla být nějaká temp data ze serveru, tak klidně smažte jak uznáte. U procesů nevím, asi by šlo vypnout něco z volitelných rozšíření NextCloudu. Případné doručování mailů s minutovým zpožděním mi vůbec nevadí. Další řešení výhledově, jak uznáte.
V blízké době nikdo další na Gitlab nepřistupuje. Díky!
Mno, tak to nepomohlo.
Takže dále zkouším
vm.swappiness = 20
místo výchozích 60, aby kernel swap používal v méně případechNerad bych to zakřikl, ale současný stav se mi zatím líbí. Pokud to bude bez problémů držet ještě v úterý, zkusím vrátit původní verzi kernelu a nastavení swapu bych ponechal bez dalších změn. Ty 4 GB se zdají být adekvátní.
Mezitím jsem implementoval zmíněnou změnu v ClamAV. Nyní tedy na serveru jedou dvě instance antivirové služby. První pracuje s databázemi udržovanými přímo ClamAV a podružnými databázemi třetích stran aktualizovanými pouze párkrát denně. Reload takové databáze proběhne nejvýše jednou za hodinu a to pouze pokud došlo ke změnám v definicích. Druhá instance pak obsluhuje pouze onu konstantně se měnící adaptivní databázi. Celá tato instance zabírá cca 17 MB RAM, samotná databáze cca polovinu z toho, a její reload proběhne za méně než vteřinu, takže místo původního intervalu jednou za pět minut se nyní aktualizuje každou minutu.
Nevím proč mě něco takového nenapadlo dřív. Když jsem dva roky zpátky načítání té adaptivní databáze implementoval, viděl jsem, že to výkonnostně není žádná bomba, což byl taky důvod proč jsem zvolil interval pěti minut i přesto, že správce té databáze doporučuje aktualizovat po minutě. Po pěti už to bylo "good enough". Ostatní servery které spravuji jsou dimenzované dostatečně a problémy to nezpůsobuje, ale ten váš je nacpaný jak klaunovské auto, takže tam se taková optimalizace určitě hodí.
Anojofurt. Však jsem říkal, že když vydrží do úterka, tak ho rozbiju sám, abyste si nezvykal, že to máte zas stabilní.
Jako viník byl identifikován kernel 5.13. S tou 5.11 to frčelo dva dny bez náznaků problému. Dopoledne jsem vrátil zpět tu 5.13 aniž bych měnil cokoliv jiného a do dvou hodin to šlo na tlamu.
Takže teď jsem tam zpátky vrátil kernel 5.11 a zamrazil jej, aby se neupdatoval. Taky jsem ukradl zpátky 2 GB swapu, protože ty předchozí 2 GB by podle všeho měly stačit, zvlášť s tou úpravou
vm.swappiness
. Teď už to zas nechám nějakou dobu být. Uvidím, jestli se mu nebude o víkendu chtít vyrobit na to nějaký bugreport Canonicalu, ale to bych Vám dal vědět ještě předtím než to zas rozbiju.Děkuji mockrát za všechny kungfu pohyby! uvidíme, věřím že bude ode mne chvíli klid :)
JP
tady píší o fixu nějaké kritické chyby, víc tomu nerozumim, nechám na vás... https://about.gitlab.com/releases/2022/03/31/critical-security-release-gitlab-14-9-2-released/#static-passwords-inadvertently-set-during-omniauth-based-registration
Zprávu jsem postřehl. OmniAuth nepoužíváme, nicméně ty ostatní zranitelnosti taky nejsou pěkné, takže máme aktualizováno na 14.9.2.
Děkuji za tu aktualizaci, pokoušel jsem se najít kde je v GitLabu info o verzi, ale zatim nevím.
Na stránce s nápovědou - https://git.spotter.cz/help