El fitxer d'intercanvi que faltava i que va bloquejar els nostres servidors

El 24 de setembre, un dels nostres servidors de producció va deixar de respondre. L'equilibrador de càrrega el va marcar com a no saludable i la nostra eina d'ordres remotes no hi podia arribar, però no s'havia caigut res ni s'havia matat cap procés per fer servir massa memòria. El servidor estava fent thrashing: sense espai de swap i amb contenidors autoritzats a fer servir més memòria de la que tenia la màquina, Linux passava el temps desallotjant i rellegint els fitxers que necessitava per executar-se, i gairebé no avançava. Afegir un fitxer de swap de 2 GB a cada servidor ho va arreglar. La lliçó més interessant era sobre els controls de salut.

Com es va veure el «bloqueig»

• Els controls de salut de l'equilibrador es van esgotar en aquell servidor.
• Les ordres enviades via AWS Systems Manager quedaven en «Pending» i mai no s'executaven.
• No hi havia cap assassinat per memòria insuficient als registres. Cap procés havia mort.

Una setmana abans havíem mogut la producció a servidors ARM més petits amb 2 GB de RAM cadascun. El nostre servidor de staging, encara més petit, s'havia bloquejat de la mateixa manera mentre descomprimia una imatge de contenidor durant un desplegament.

Per què no hi havia cap error de memòria?

Linux només mata un procés quan de debò es queda sense memòria que pugui recuperar. Abans d'arribar a aquest punt, recupera memòria de la memòria cau de pàgines: les còpies de fitxers que manté a RAM, inclòs el codi de cada programa en execució.

Als nostres servidors, els límits de memòria combinats dels contenidors sumaven uns 3,3 GB en una màquina amb uns 1,8 GB utilitzables. Normalment no els fan servir tots al seu límit alhora. Quan ho feien, el nucli seguia desallotjant codi de programa de la memòria cau per fer lloc, i després l'havia de tornar a llegir del disc en el moment que aquell codi tornava a executar-se. Aquest cicle, el thrashing, pot deixar una màquina gairebé completament sense resposta mentre tècnicament mai no s'ha quedat sense memòria. Per això no es mata res, i no es recupera res.

Sense swap, el nucli no té on posar la memòria que s'ha reservat però s'utilitza poc, i per això l'ha de treure de la memòria cau.

La solució

L'script d'arrencada del servidor ara crea un fitxer de swap de 2 GB amb un valor de swappiness baix (10) cada vegada que un servidor s'arrenca o es repara. Un swappiness baix vol dir que el nucli encara prefereix mantenir la memòria de treball a RAM, però les pàgines poc usades poden anar al disc en lloc de forçar el codi de programa fora de la memòria cau. Ho vam aplicar en directe als dos servidors de producció i a staging, i la canonada de desplegament republica l'script d'arrencada a cada desplegament de producció, de manera que un servidor substituït també el rep.

La part que ens preocupava més: el servidor no saludable es quedava

El nostre grup de servidors feia servir controls de salut d'EC2, és a dir, «la màquina està en marxa?», i no controls de salut de l'equilibrador de càrrega, és a dir, «respon a les peticions?». Així, un servidor al qual l'equilibrador havia donat per perdut seguia sent sa per al grup. Mai no seria substituït. La producció funcionaria silenciosament amb un sol servidor fins que algú ho notés i reiniciés l'altre.

Canviar el grup a controls de salut de l'equilibrador sembla la solució òbvia, però no és senzill per a nosaltres: durant un desplegament, els servidors responen a propòsit amb un error al seu endpoint de salut perquè l'equilibrador els buidi (vegeu com hem aconseguit desplegaments amb zero 502). Un grup que substituís servidors amb aquest senyal els substituiria enmig de cada desplegament.

Així que, de moment, hem afegit un pas a la nostra llista de comprovació de desplegament: després de cada desplegament, comprova la salut de cada destí a l'equilibrador, no només si la feina de desplegament ha passat. Si les ordres a un servidor es queden en «Pending», està fent thrashing: reinicia'l; ja està fora de la rotació.

Què ens hem endut

• «No caure» no és «sa». El thrashing no produeix cap error, només una lentitud tan extrema que la màquina deixa de respondre.
• Els servidors petits necessiten swap. Fins i tot una mica, amb swappiness baix, dona al nucli un lloc on posar la memòria freda.
• Els límits de memòria que sumen més que la màquina són una aposta. De vegades la perds. Sàpigues quan l'has feta.
• Sàpigues en quin control de salut confia el teu autoescalat. Un control que només pregunta «la VM està encesa?» no substituirà un servidor que ha deixat de funcionar.