Chýbajúci swap súbor, ktorý zamrazil naše servery

1. septembra jeden z našich produkčných serverov prestal odpovedať. Load balancer ho označil ako nezdravý a náš nástroj na vzdialené príkazy sa k nemu nedostal — no nič nespadlo a nič nebolo zabité pre príliš veľkú spotrebu pamäte. Server bol v thrashingu: bez swap priestoru a s kontajnermi, ktorým bolo povolené použiť viac pamäte, než mal stroj k dispozícii, Linux trávil čas vyhadzovaním a opätovným načítavaním súborov, ktoré potreboval na beh, a takmer nepostupoval. Pridanie 2 GB swap súboru na každý server problém vyriešilo. Zaujímavejšie poučenie sa týkalo health checkov.

Ako vyzeral „zamrznutý“ stav

• Health checky load balancera na tomto serveri vypršali.
• Príkazy poslané cez AWS Systems Manager zostávali v stave „Pending“ a nikdy sa nespustili.
• V logoch nebolo žiadne zabitie pre nedostatok pamäte. Žiadny proces nezomrel.

O týždeň skôr sme presunuli produkciu na menšie ARM servery s 2 GB RAM na každom. Náš staging server — ešte menší — zamrzol rovnakým spôsobom pri rozbaľovaní container image-u počas deployu.

Prečo žiadna chyba pamäte?

Linux zabije proces až vtedy, keď naozaj dôjde pamäť, ktorú možno uvoľniť. Až dovtedy uvoľňuje pamäť z page cache — kópií súborov, ktoré drží v RAM, vrátane kódu každého bežiaceho programu.

Na našich serveroch sa kombinované limity pamäte kontajnerov sčítali na zhruba 3,3 GB na stroji s približne 1,8 GB použiteľnými. Zvyčajne ich všetky naraz nevyužijú na maximum. Keď to však urobili, kernel stále vyhadzoval kód programov z cache, aby uvoľnil miesto, a v momente, keď sa ten kód znova spustil, ho musel čítať späť z disku. Tento cyklus — thrashing — dokáže stroj takmer úplne vyradiť z odozvy, pričom technicky nikdy nedôjde pamäť. Nič sa teda nezabije a nič sa nezotaví.

Bez swapu nemá kernel kam odložiť pamäť, ktorá je alokovaná, no zriedka sa používa, a preto ju musí vziať z cache.

Oprava

Bootstrap skript servera teraz pri každom štarte alebo oprave servera vytvorí 2 GB swap súbor s nízkou hodnotou swappiness (10). Nízka hodnota znamená, že kernel stále uprednostňuje držanie pracovnej pamäte v RAM, ale zriedka používané stránky sa môžu presunúť na disk namiesto toho, aby vytláčali kód programov z cache. Zmenu sme aplikovali živo na oba produkčné servery a na staging a deploy pipeline publikuje bootstrap skript pri každom produkčnom deployi, takže aj nahradený server ju dostane.

Čo nás znepokojilo viac: nezdravý server ostal

Naša skupina serverov používala EC2 health checky — „beží stroj?“ — a nie health checky load balancera — „odpovedá na požiadavky?“. Server, ktorý load balancer vzdal, bol pre skupinu stále zdravý. Nikdy by nebol nahradený. Produkcia by tíško bežala na jednom serveri, kým by si to niekto nevšimol a nereštartoval ten druhý.

Prepnutie skupiny na health checky load balancera sa zdá ako zrejmá oprava, no pre nás nie je priamočiare: počas deployu servery úmyselne odpovedajú na svoj health endpoint chybou, aby ich balancer vyradil z prevádzky (pozri ako sme dostali deploye na nula 502 chýb). Skupina, ktorá by servery nahrádzala podľa tohto signálu, by ich nahrádzala uprostred každého deployu.

Zatiaľ sme preto pridali krok do nášho deploy checklistu: po každom deployi skontrolovať zdravie každého cieľa na load balanceri, nielen či deploy job prešiel. Ak príkazy pre server zostávajú v stave „Pending“, je to thrashing — reštartujte ho; aj tak je už mimo prevádzky.

Čo sme si z toho odniesli

• „Nepadá“ neznamená „zdravé“. Thrashing nevytvára žiadnu chybu, len spomalenie tak extrémne, že stroj prestane odpovedať.
• Malé servery potrebujú swap. Aj malý, s nízkou hodnotou swappiness, dá kernelu kam odložiť studenú pamäť.
• Limity pamäte, ktoré sa sčítajú na viac, než má stroj, sú stávka. Niekedy ju prehráte. Vedzte, že ste na ňu vsadili.
• Vedzte, ktorému health checku vaše autoškálovanie dôveruje. Health check, ktorý sa len pýta „beží VM?“, nenahradí server, ktorý prestal fungovať.