Puuttuva swap-tiedosto, joka jäädytti palvelimemme

Syyskuun 24. päivänä yksi tuotantopalvelimistamme lakkasi vastaamasta. Kuormantasaaja merkitsi sen epäkunnossa olevaksi, eikä etäkomentotyökalumme tavoittanut sitä, mutta mikään ei ollut kaatunut eikä mikään prosessi ollut tapettu liiallisen muistinkäytön takia. Palvelin oli jatkuvassa vaihdossa (thrashing): ilman swap-tilaa ja konttien sallittua muistinkäyttöä enemmän kuin koneessa oli, Linux käytti aikansa sivumuistin tiedostojen poistamiseen ja uudelleenlukemiseen, jotka se tarvitsi ajaakseen itseään, eikä edistynyt juuri lainkaan. 2 Gt:n swap-tiedoston lisääminen jokaiselle palvelimelle korjasi tilanteen. Kiinnostavampi opetus koski terveystarkistuksia.

Miltä "jumittunut" näytti

• Kuormantasaajan terveystarkistukset aikakatkaistiin kyseisellä palvelimella.
• AWS Systems Managerin kautta lähetetyt komennot jäivät tilaan "Pending" eivätkä koskaan ajautuneet.
• Lokeissa ei ollut muistin loppumisen tappoa. Mikään prosessi ei kuollut.

Viikkoa aiemmin olimme siirtäneet tuotannon pienempiin ARM-palvelimiin, joissa oli 2 Gt RAM:ia kussakin. Stagingpalvelimemme, joka oli vielä pienempi, oli jäätynyt samalla tavalla purkaessaan konttikuvaa käyttöönoton aikana.

Miksi muistivirhettä ei tullut?

Linux tappaa prosessin vasta, kun muisti todella loppuu, jota se voi vapauttaa. Ennen sitä se vapauttaa muistia sivumuistista, eli tiedostojen kopioista, joita se pitää RAM-muistissa, mukaan lukien jokaisen käynnissä olevan ohjelman koodi.

Palvelimillamme konttien yhdistetyt muistirajat olivat noin 3,3 Gt koneessa, jossa oli noin 1,8 Gt käytettävää muistia. Normaalisti ne eivät kaikki käytä rajaansa yhtä aikaa. Kun niin kuitenkin kävi, ydin poisti jatkuvasti ohjelmakoodia välimuistista tehdäkseen tilaa, ja luki sen takaisin levyltä heti, kun koodi ajettiin uudelleen. Tämä kierre, thrashing, voi tehdä koneesta lähes täysin reagoimattoman, vaikka muisti ei teknisesti lopu. Joten mitään ei tapeta, eikä mikään toivu.

Ilman swapia ytimellä ei ole minne siirtää varattua mutta harvoin käytettyä muistia, joten se ottaa sen sivumuistista.

Korjaus

Palvelimen käynnistysskripti luo nyt 2 Gt:n swap-tiedoston matalalla swappiness-arvolla (10) joka kerta, kun palvelin käynnistyy tai korjataan. Matala swappiness tarkoittaa, että ydin pitää yhä mieluummin työmuistin RAM-muistissa, mutta harvoin käytetyt sivut voivat siirtyä levylle sen sijaan, että ohjelmakoodi työnnettäisiin pois välimuistista. Teimme tämän suoraan molemmille tuotantopalvelimille ja stagingiin, ja käyttöönottoputki julkaisee käynnistysskriptin uudelleen jokaisella tuotantojulkaisulla, joten korvattu palvelin saa sen myös.

Mikä huoletti enemmän: epäkunnossa oleva palvelin jäi paikalleen

Palvelinryhmämme käytti EC2-terveystarkistuksia, eli kysymystä "onko kone päällä?", ei kuormantasaajan terveystarkistuksia, eli kysymystä "vastaako se pyyntöihin?". Joten palvelin, jonka kuormantasaaja oli jo hylännyt, oli ryhmän näkökulmasta yhä terve. Sitä ei koskaan korvattaisi. Tuotanto pyörisi hiljaa yhdellä palvelimella, kunnes joku huomaisi sen ja käynnistäisi toisen uudelleen.

Ryhmän vaihtaminen kuormantasaajan terveystarkistuksiin kuulostaa ilmeiseltä korjaukselta, mutta se ei ole suoraviivaista meille: käyttöönoton aikana palvelimet vastaavat tarkoituksella virheellä terveysendpointissaan, jotta kuormantasaaja tyhjentää ne (katso miten saimme käyttöönotot nollaan 502-virheeseen). Ryhmä, joka korvaa palvelimia tuon signaalin perusteella, korvaisi ne jokaisen käyttöönoton keskellä.

Lisäsimme siksi toistaiseksi käyttöönottotarkistuslistaan vaiheen: jokaisen käyttöönoton jälkeen tarkistetaan jokaisen kohteen terveys kuormantasaajalta, ei vain se, läpäisikö käyttöönottotyö. Jos komennot palvelimelle jäävät tilaan "Pending", palvelin on vaihtamassa: käynnistä se uudelleen, se on jo pois käytöstä.

Mitä tästä opimme

• "Ei kaatunut" ei tarkoita "terve". Thrashing ei tuota virhettä, vain niin äärimmäisen hitautta, että kone lakkaa vastaamasta.
• Pienet palvelimet tarvitsevat swapin. Jopa vähän, matalalla swappinessillä, antaa ytimelle paikan, johon kylmä muisti voi mennä.
• Muistirajat, jotka yhteensä ylittävät koneen, ovat panos. Joskus häviät sen. Tiedä, milloin olet lyönyt vetoa.
• Tiedä, mihin terveystarkistukseen automaattinen skaalaus luottaa. Tarkistus, joka kysyy vain "onko virtuaalikone päällä?", ei korvaa palvelinta, joka on lakannut toimimasta.