Swap-filen som saknades och fick våra servrar att frysa

Den 24 september slutade en av våra produktionsservrar att svara. Load balancern markerade den som ohälsosam och vårt verktyg för fjärrkommandon kunde inte nå den, men ingenting hade kraschat och ingen process hade dödats för att den använde för mycket minne. Servern trashade: utan swap-utrymme och med containrar som fick använda mer minne än maskinen hade, lade Linux all sin tid på att kasta ut och läsa in om de filer den behövde för att köra, och kom nästan ingenstans. Att lägga till en 2 GB swap-fil på varje server löste problemet. Den mer intressanta lärdomen gällde hälsokontroller.

Så såg det “hängda” ut

• Load balancerns hälsokontroller tog timeout på den servern.
• Kommandon som skickades via AWS Systems Manager låg kvar i “Pending” och kördes aldrig.
• Det fanns ingen out-of-memory-död i loggarna. Ingen process hade dött.

En vecka tidigare hade vi flyttat produktionen till mindre ARM-servrar med 2 GB RAM vardera. Vår staging-server, ännu mindre, hade frusit på samma sätt när den packade upp en container-image under en deploy.

Varför inget minnesfel?

Linux dödar bara en process när det verkligen tar slut på minne som kan återtas. Innan det sker återtar kärnan minne från page cache, de kopior av filer den håller i RAM, inklusive koden för varje program som kör.

På våra servrar summerades containrarnas minnesgränser till ungefär 3,3 GB på en maskin med ungefär 1,8 GB användbart minne. Normalt använder de inte alla sin gräns samtidigt. När de gjorde det kastade kärnan hela tiden ut programkod ur cachen för att skapa utrymme, och fick sedan läsa tillbaka den från disken så fort koden kördes igen. Den cykeln, trashing, kan göra en maskin nästan helt oresponsiv utan att den tekniskt sett någonsin tar slut på minne. Så ingenting dödas, och ingenting återhämtar sig.

Utan swap har kärnan ingenstans att lägga minne som är allokerat men sällan används, så den måste ta det från cachen i stället.

Lösningen

Serverns bootstrap-skript skapar nu en 2 GB swap-fil med låg swappiness (10) varje gång en server startas eller repareras. Låg swappiness betyder att kärnan fortfarande helst håller arbetsminne i RAM, men sällan använda sidor kan flyttas till disken i stället för att tvinga ut programkod ur cachen. Vi tillämpade det live på båda produktionsservrarna och på staging, och deploy-pipelinen publicerar bootstrap-skriptet på nytt vid varje produktionsdeploy, så att en ersatt server också får det.

Det som oroade oss mer: den ohälsosamma servern blev kvar

Vår servergrupp använde EC2-hälsokontroller, “körs maskinen?”, och inte load balancer-hälsokontroller, “svarar den på förfrågningar?”. En server som load balancern hade gett upp på var alltså fortfarande frisk i gruppens ögon. Den skulle aldrig bytas ut. Produktionen skulle tyst köra på en enda server tills någon märkte det och startade om den andra.

Att byta gruppen till load balancer-hälsokontroller låter som den uppenbara lösningen, men det är inte okomplicerat för oss: under en deploy svarar servrarna medvetet med ett fel på sin hälsoendpoint så att balancern dränerar dem (se hur vi fick deploys till noll 502:or). En grupp som byter ut servrar på den signalen skulle byta ut dem mitt under varje deploy.

Så för närvarande har vi lagt till ett steg i vår deploy-checklista: efter varje deploy kontrollerar vi varje målservers hälsa i load balancern, inte bara om deploy-jobbet gick igenom. Om kommandon till en server ligger kvar i “Pending” trashar den, starta om den; den är redan ur rotation.

Det vi tog med oss

• “Inte kraschad” är inte samma sak som “frisk”. Trashing ger inget fel, bara en långsamhet så extrem att maskinen slutar svara.
• Små servrar behöver swap. Även lite, med låg swappiness, ger kärnan någonstans att lägga kallt minne.
• Minnesgränser som summerar till mer än maskinen är ett vad. Ibland förlorar man det. Ta reda på när du har satsat.
• Känn till vilken hälsokontroll din autoskalning litar på. En hälsokontroll som bara frågar “är VM:en påslagen?” byter inte ut en server som slutat fungera.