Den manglende swap-filen som frøs serverne våre

Den 24. september sluttet én av produksjonsserverne våre å svare. Lastbalanseren markerte den som usunn, og verktøyet vårt for fjernkommandoer fikk ikke kontakt med den. Men ingenting hadde krasjet, og ingen prosess var drept for å bruke for mye minne. Serveren var i trashing: uten swap-plass, og med containere som fikk bruke mer minne enn maskinen hadde, brukte Linux all tid på å fjerne og lese på nytt filene den trengte for å kjøre, og kom nesten ingen vei. Å legge til en swap-fil på 2 GB på hver server løste det. Den mest interessante lærdommen gjaldt helsesjekker.

Hva «hengt» så ut som

• Lastbalanserens helsesjekker fikk timeout på den serveren.
• Kommandoer sendt via AWS Systems Manager sto i «Pending» og ble aldri kjørt.
• Det fantes ingen out-of-memory-drap i loggene. Ingen prosess døde.

En uke tidligere hadde vi flyttet produksjon til mindre ARM-servere med 2 GB RAM hver. Staging-serveren vår, som er enda mindre, hadde frosset på samme måte under utpakking av et containerbilde under en deploy.

Hvorfor ingen minnefeil?

Linux dreper bare en prosess når det virkelig er tomt for minne den kan frigjøre. Før det punktet henter kjernen minne fra sidecachen: kopiene av filer den holder i RAM, inkludert koden til hvert kjørende program.

På serverne våre var containerenes samlede minnegrenser omtrent 3,3 GB, på en maskin med omtrent 1,8 GB brukbart. Normalt bruker de ikke alle grensen samtidig. Når de gjorde det, fortsatte kjernen å fjerne programkode fra cachen for å få plass, og måtte så lese den tilbake fra disk så snart koden kjørte igjen. Den syklusen, trashing, kan gjøre en maskin nesten helt uresponsiv uten at den teknisk sett går tom for minne. Så ingenting blir drept, og ingenting kommer seg.

Uten swap har kjernen ingen plass å legge minne som er allokert, men sjelden brukt, så den må ta det fra cachen i stedet.

Løsningen

Bootstrap-skriptet for serveren lager nå en swap-fil på 2 GB med lav swappiness (10) hver gang en server starter eller repareres. Lav swappiness betyr at kjernen fortsatt helst holder arbeidsminne i RAM, men sjelden brukte sider kan flyttes til disk i stedet for at programkode tvinges ut av cachen. Vi brukte den live på begge produksjonsserverne og på staging. Deploy-pipelinen publiserer bootstrap-skriptet på nytt ved hver produksjonsdeploy, slik at en erstattet server også får den.

Det som bekymret oss mer: den usunne serveren ble stående

Servergruppen vår brukte EC2-helsesjekker, som spør «kjører maskinen?», og ikke lastbalanserens helsesjekker, som spør «svarer den på forespørsler?». Så en server som lastbalanseren hadde gitt opp, var fortsatt frisk for gruppen. Den ville aldri bli erstattet. Produksjon ville stille og rolig kjøre på én server til noen la merke til det og startet den andre på nytt.

Å bytte gruppen til lastbalanserens helsesjekker høres ut som den opplagte løsningen, men det er ikke rett fram for oss. Under en deploy svarer serverne med vilje en feil på helseendepunktet sitt, slik at lastbalanseren tømmer dem (se hvordan vi fikk deploys ned til null 502-feil). En gruppe som erstatter servere på det signalet, ville erstattet dem midt i hver deploy.

Så foreløpig har vi lagt til et steg i deploy-sjekklisten vår: Etter hver deploy sjekker vi helsen til hvert mål på lastbalanseren, ikke bare om deploy-jobben gikk bra. Hvis kommandoer til en server står i «Pending», trasher den. Start den på nytt; den er allerede tatt ut av rotasjon.

Det vi tok med oss

• «Ikke krasjer» er ikke «frisk». Trashing gir ingen feil, bare en slags treghet så ekstrem at maskinen slutter å svare.
• Små servere trenger swap. Selv litt, med lav swappiness, gir kjernen et sted å legge kald minne.
• Minnegrenser som til sammen er mer enn maskinen har, er et veddemål. Noen ganger taper du det. Kjenn til når du har satset.
• Vit hvilken helsesjekk autoskaleringen din stoler på. En helsesjekk som bare spør «er VM-en på?», erstatter ikke en server som har sluttet å fungere.