Trūkstamas swap failas, kuris sustabdė mūsų serverius

Rugsėjo 24 d. vienas mūsų gamybos serveris nustojo atsakinėti. Apkrovos balansuotojas jį pažymėjo kaip neveikiantį, o mūsų nuotolinių komandų įrankis negalėjo jo pasiekti – bet niekas nenulūžo ir niekas nebuvo nužudytas dėl per didelio atminties naudojimo. Serveris trikdė: be swap vietos, o konteineriams leista naudoti daugiau atminties, nei turėjo mašina, Linux leido laiką iškeldamas ir vėl skaitydamas failus, kurių reikėjo vykdymui, ir beveik nepadarydamas pažangos. 2 GB swap failas kiekviename serveryje tai ištaisė. Įdomesnė pamoka buvo apie sveikatos patikras.

Kaip atrodė „užstrigimas“

• Apkrovos balansuotojo sveikatos patikros tame serveryje baigėsi laiko limitu.
• Komandos, siunčiamos per AWS Systems Manager, liko būsenoje „Pending“ ir niekada nevykdytos.
• Žurnaluose nebuvo atminties perpildymo nužudymo. Joks procesas nežuvo.

Prieš savaitę perkėlėme gamybą į mažesnius ARM serverius, kiekviename su 2 GB RAM. Mūsų bandomasis serveris – dar mažesnis – taip pat užstrigo, kai diegimo metu išpakavo konteinerio vaizdą.

Kodėl be atminties klaidos?

Linux nužudo procesą tik tada, kai iš tikrųjų pritrūksta atminties, kurią galima atgauti. Iki tol jis atgauna atmintį iš puslapių talpyklos – failų kopijų, kurias laiko RAM, įskaitant kiekvienos veikiančios programos kodą.

Mūsų serveriuose konteinerių bendri atminties limitai siekė apie 3,3 GB mašinoje, kurioje naudojama apie 1,8 GB. Paprastai jie visi nenaudoja savo limito vienu metu. Kai naudojo, branduolys nuolat iškeldavo programos kodą iš talpyklos, kad sukurtų vietos, o vėliau jį vėl turėdavo nuskaityti iš disko tą akimirką, kai tas kodas vėl paleidžiamas. Tas ciklas – trikdžiai (thrashing) – gali padaryti mašiną beveik visiškai nereaguojančią, nors techniškai atminties nepritrūksta. Taigi niekas nenužudomas ir niekas neatsigauna.

Be swap branduolys neturi kur padėti paskirtos, bet retai naudojamos atminties, todėl ją turi paimti iš talpyklos.

Pataisa

Serverio paleidimo scenarijus dabar sukuria 2 GB swap failą su žemu swappiness nustatymu (10) kiekvieną kartą, kai serveris paleidžiamas arba remontuojamas. Žemas swappiness reiškia, kad branduolys vis dar teikia pirmenybę darbinei atminčiai laikyti RAM, bet retai liečiami puslapiai gali būti perkelti į diską, o ne priversti programos kodą iš talpyklos. Pritaikėme tai tiesiogiai abiem gamybos serveriams ir bandomajam serveriui, o diegimo procesas kiekvieno gamybos diegimo metu iš naujo paskelbia paleidimo scenarijų, kad pakeistas serveris taip pat jį gautų.

Labiau nerimavo tai, kad neveikiantis serveris liko

Mūsų serverių grupė naudojo EC2 sveikatos patikras – „ar mašina veikia?“ – o ne apkrovos balansuotojo sveikatos patikras – „ar ji atsako į užklausas?“. Taigi serveris, kurio nebeturėjo apkrovos balansuotojas, grupei vis tiek atrodė sveikas. Jis niekada nebūtų pakeistas. Gamyba tyliai veiktų vienu serveriu, kol kas nors nepastebėtų ir neperkrautų kito.

Perjungti grupę į apkrovos balansuotojo sveikatos patikras atrodo akivaizdus sprendimas, bet mums tai nėra paprasta: diegimo metu serveriai tyčia atsako į savo sveikatos galinį tašką klaida, kad balansuotojas juos išleistų (žr. kaip pasiekėme nulį 502 klaidų diegimuose). Grupė, kuri keičia serverius pagal tą signalą, keistų juos kiekvieno diegimo viduryje.

Todėl kol kas į diegimo kontrolinį sąrašą įtraukėme žingsnį: po kiekvieno diegimo patikrinti kiekvieno taikinio sveikatą apkrovos balansuotojuje, o ne tik tai, ar diegimo darbas praėjo. Jei komandos serveriui lieka būsenoje „Pending“, jis trikdo – perkraukite jį; jis jau nebėra eilėje.

Ką iš to pasiėmėme

• „Nenulūžimas“ nereiškia „sveikumo“. Trikdžiai sukelia klaidą nesukeldami – tik tokį lėtumą, kad mašina nustoja atsakinėti.
• Maži serveriai reikalauja swap. Net nedidelis, su žemu swappiness, suteikia branduoliui vietą šaltai atminčiai.
• Atminties limitai, kurie susideda į daugiau, nei turi mašina, yra statymas. Kartais pralaimite. Žinokite, kada tai padarėte.
• Žinokite, kuria sveikatos patikra pasitiki jūsų automatinis mastelis. Sveikatos patikra, kuri klausia tik „ar VM įjungta?“, nepakeis serverio, kuris nustojo veikti.