Puuduv swap-fail, mis külmutas meie serverid

1. septembril lakkas üks meie tootmisserver vastamast. Koormusjaotaja märkis selle tervetuks ja meie kaugkäsutööriist ei jõudnud sinna, aga miski polnud kokku kukkunud ega tapetud liigse mälukasutuse eest. Server oli pidevas ümberlaadimises: ilma swap-ruumita ja konteinerite lubatud mäluga, mis ületas masina mälu, veetis Linux aega lehtpuhvrist failide väljutamisel ja uuesti lugemisel, mida ta vajas töötamiseks, ja edenes peaaegu üldse. Lisades igale serverile 2 GB swap-faili, lahenes probleem. Huvitavam õppetund puudutas tervisekontrolle.

Kuidas „kinni jäänud“ välja nägi

• Koormusjaotaja tervisekontrollid aegusid selles serveris.
• AWS Systems Manageri kaudu saadetud käsud jäid olekusse „Pending“ ega käivitunud kunagi.
• Logides ei olnud mälu täitumise tapmist. Ükski protsess ei surnud.

Nädal varem olime viinud tootmise väiksematele ARM-serveritele, igaüks 2 GB RAM-iga. Meie stagingu server, veel väiksem, oli külmunud samamoodi konteinerpildi lahtipakkimise ajal deploy-i käigus.

Miks polnud mälu viga?

Linux tapab protsessi ainult siis, kui tal tõesti otsa saab mälu, mida saab tagasi võtta. Enne seda punkti võtab ta mälu tagasi lehtpuhvrist — koopiatest failidest, mida ta hoiab RAM-is, sealhulgas iga töötava programmi koodist.

Meie serverites ületas konteinerite mälupiirangute summa umbes 3,3 GB masinas, millel on umbes 1,8 GB kasutatavat. Tavaliselt ei kasuta nad kõik korraga oma piiri. Kui nad seda tegid, väljutas kerneli ruumi tegemiseks programmikoodi puhvrist ja luges selle siis kettalt tagasi kohe, kui see kood uuesti käivitus. See tsükkel, ümberlaadimine, võib masina peaaegu täielikult reageerimatuks muuta, kusjuures tehniliselt mälu ei saa kunagi otsa. Nii ei tapeta midagi ja midagi ei taastu.

Swap-ruumita pole kernelil kuhugi panna eraldatud, aga harva kasutatavat mälu, nii et ta peab selle võtma puhvrist.

Parandus

Serveri bootstrap-skript loob nüüd 2 GB swap-faili madala swappiness-seadistusega (10) iga kord, kui server käivitub või parandatakse. Madal swappiness tähendab, et kernel eelistab ikka hoida töömälu RAM-is, aga harva puudutatud lehed saavad liikuda kettale, selle asemel et sundida programmikoodi puhvrist välja. Rakendasime seda elavalt mõlemale tootmisserverile ja stagingule, ning deploy-torustik avaldab bootstrap-skripti igal tootmise deploy-l uuesti, nii et asendatud server saab selle samuti.

See, mis meid rohkem murdis: tervetuks märgitud server jäi alles

Meie serverigrupp kasutas EC2 tervisekontrolle — „kas masin töötab?“ — mitte koormusjaotaja tervisekontrolle — „kas see vastab päringutele?“. Nii oli server, millest koormusjaotaja oli loobunud, grupi jaoks ikka tervis. Seda ei asendataks kunagi. Tootmine jookseks vaikselt ühel serveril, kuni keegi seda märkaks ja teist taaskäivitaks.

Grupi lülitamine koormusjaotaja tervisekontrollidele kõlab ilmse parandusena, aga see pole meile lihtne: deploy-i ajal vastavad serverid tahtlikult oma tervise lõpp-punktile veaga, et jaotaja need tühjendaks (vaata, kuidas saime deploy-d nullini 502-vigadeni). Grupp, mis asendaks servereid selle signaali järgi, asendaks neid iga deploy-i keskel.

Nii lisasime praegu oma deploy-kontrollnimekirja sammu: pärast iga deploy-d kontrolli iga sihtmärgi tervist koormusjaotajal, mitte ainult seda, kas deploy-töö läks läbi. Kui käsud serverisse jäävad olekusse „Pending“, siis see ümberlaadib — taaskäivita see; see on juba rotatsioonist väljas.

Mida sellest õppisime

• „Ei kuku kokku“ ei tähenda „tervet“. Ümberlaadimine ei anna viga, ainult aeglust, mis on nii äärmuslik, et masin lakkab vastamast.
• Väikesed serverid vajavad swap-i. Isegi väikest, madala swappiness-iga, mis annab kernelile koha, kuhu külma mälu panna.
• Mälupiirangud, mis liituvad rohkem kui masin, on kihlvedu. Mõnikord kaotad. Teadke, millal olete seda teinud.
• Teadke, millisest tervisekontrollist teie automaatskaleerimine usaldust võtab. Tervisekontroll, mis küsib ainult „kas VM on sisse lülitatud?“, ei asenda serverit, mis on lakanud töötamast.