Nedostajuća swap datoteka koja je zamrznula naše servere

1. rujna jedan od naših produkcijskih servera prestao je odgovarati. Load balancer ga je označio kao nezdravog, a naš alat za daljinske naredbe nije mogao doći do njega. Ali ništa se nije srušilo i ništa nije ubijeno zbog prevelike potrošnje memorije. Server je bio u thrashingu: bez swap prostora i uz kontejnere kojima je bilo dopušteno koristiti više memorije nego što stroj ima, Linux je trošio vrijeme na izbacivanje i ponovno čitanje datoteka potrebnih za rad, a napredovao je gotovo nikako. Dodavanje swap datoteke od 2 GB na svaki server riješilo je problem. Zanimljivija lekcija ticala se provjera zdravlja.

Kako je izgledao „zamrznut”

• Provjere zdravlja load balancera na tom serveru istekle su.
• Naredbe poslane kroz AWS Systems Manager stajale su na „Pending” i nikad se nisu izvršile.
• U logovima nije bilo grešaka zbog nedostatka memorije. Nijedan proces nije umro.

Tjedan prije prebacili smo produkciju na manje ARM servere s 2 GB RAM-a po stroju. Naš staging server, još manji, na isti je način zamrznuo dok je raspakiravao kontejnersku sliku tijekom deploya.

Zašto nema greške s memorijom?

Linux ubija proces tek kad zaista ostane bez memorije koju može vratiti. Prije toga oslobađa memoriju iz page cachea, odnosno kopija datoteka koje drži u RAM-u, uključujući kod svakog pokrenutog programa.

Na našim serverima zbirna memorijska ograničenja kontejnera iznosila su oko 3,3 GB na stroju s oko 1,8 GB iskoristivo. Obično ne koriste sva svoj limit istovremeno. Kad su ga koristili, kernel je neprestano izbacivao kod programa iz cachea da napravi mjesta, a onda ga je morao ponovno čitati s diska čim bi se taj kod ponovno izvršio. Taj ciklus, thrashing, može učiniti stroj gotovo potpuno nereagirajućim, a da tehnički nikad ne ostane bez memorije. Zato se ništa ne ubija i ništa se ne oporavi.

Bez swapa kernel nema gdje staviti memoriju koja je alocirana ali se rijetko koristi, pa je mora uzeti iz cachea.

Popravak

Bootstrap skripta servera sada pri svakom pokretanju ili popravku servera kreira swap datoteku od 2 GB s niskom vrijednošću swappiness (10). Niska swappiness znači da kernel i dalje radije drži radnu memoriju u RAM-u, ali rijetko dotaknute stranice mogu otići na disk umjesto da se kod programa izbacuje iz cachea. Primijenili smo to uživo na oba produkcijska servera i na staging, a deploy pipeline ponovno objavljuje bootstrap skriptu pri svakoj produkcijskoj objavi, pa i zamijenjeni server to dobije.

Što nas je više zabrinulo: nezdravi server je ostao

Naša server grupa koristila je EC2 health checks, odnosno „radi li stroj?”, a ne load balancer health checks, odnosno „odgovara li na zahtjeve?”. Zato je server kojeg je load balancer odbacio za grupu i dalje bio zdrav. Nikad se ne bi zamijenio. Produkcija bi tiho radila na jednom serveru dok netko to ne primijeti i ne ponovno pokrene drugi.

Prebacivanje grupe na provjere zdravlja load balancera zvuči kao očito rješenje, ali za nas nije jednostavno: tijekom deploya serveri namjerno vraćaju grešku na svoj health endpoint kako bi balancer prestao slati promet na njih (vidi kako smo došli do nula 502 grešaka pri deployu). Grupa koja bi zamjenjivala servere na taj signal zamijenila bi ih usred svakog deploya.

Zato smo za sada u kontrolni popis deploya dodali korak: nakon svakog deploya provjeriti zdravlje svakog cilja na load balanceru, a ne samo je li deploy job prošao. Ako naredbe prema serveru stoje u „Pending”, on thrasha; ponovno ga pokrenite, već je izvan rotacije.

Što smo iz toga izvukli

• „Ne ruši se” nije „zdrav”. Thrashing ne proizvodi grešku, nego samo usporenost toliko ekstremnu da stroj prestane odgovarati.
• Mali serveri trebaju swap. Čak i malo, uz nisku swappiness, daje kernelu mjesto za hladnu memoriju.
• Memorijska ograničenja čiji zbroj premašuje stroj su kocka. Ponekad je izgubite. Znajte kad ste je dobili.
• Znajte kojoj provjeri zdravlja vaš autoscaling vjeruje. Provjera koja pita samo „je li VM uključen?” neće zamijeniti server koji je prestao raditi.