Sunucularımızı Donduran Eksik Takas Dosyası

24 Eylül'de üretim sunucularımızdan biri yanıt vermeyi bıraktı. Yük dengeleyici onu sağlıksız olarak işaretledi ve uzaktan komut aracımız ona ulaşamadı; ama hiçbir şey çökmemişti ve çok fazla bellek kullandığı için hiçbir süreç öldürülmemişti. Sunucu thrashing durumundaydı: takas alanı olmayan ve konteynerlerin makinenin sahip olduğundan fazla bellek kullanmasına izin verilen bir ortamda Linux, çalışmak için ihtiyaç duyduğu dosyaları önbellekten atıp yeniden okumakla zaman geçiriyor, neredeyse hiç ilerleme kaydetmiyordu. Her sunucuya 2 GB'lık bir takas dosyası eklemek sorunu çözdü. Daha ilginç olan ders, sağlık kontrolleriyle ilgiliydi.

"Takıldı" neye benziyordu?

• Yük dengeleyicinin sağlık kontrolleri o sunucuda zaman aşımına uğradı.
• AWS Systems Manager üzerinden gönderilen komutlar "Pending" durumunda bekledi ve hiç çalışmadı.
• Günlüklerde bellek yetersizliği nedeniyle bir kill yoktu. Hiçbir süreç ölmedi.

Bir hafta önce üretimi, her biri 2 GB RAM'li daha küçük ARM sunucularına taşımıştık. Staging sunucumuz, daha da küçük olan, bir dağıtım sırasında bir konteyner imajını açarken aynı şekilde donmuştu.

Neden bellek hatası yok?

Linux, bir süreci yalnızca geri alabileceği belleği gerçekten tükettiğinde öldürür. Bu noktadan önce belleği sayfa önbelleğinden geri alır. Sayfa önbelleği, dosyaların RAM'de tuttuğu kopyalardır ve çalışan her programın kodu da buna dahildir.

Sunucularımızda konteynerlerin birleşik bellek limitleri, kullanılabilir yaklaşık 1,8 GB'lık bir makinede yaklaşık 3,3 GB tutuyordu. Normalde hepsi aynı anda limitlerine yaklaşmaz. Yaklaştıklarında çekirdek, yer açmak için program kodunu önbellekten atıyor ve o kod yeniden çalıştığı anda diskten geri okumak zorunda kalıyordu. Bu döngü (thrashing), bir makinenin teknik olarak bellek tükenmeden neredeyse tamamen yanıtsız kalmasına yol açabilir. Yani hiçbir şey öldürülmez ve hiçbir şey kendini toparlamaz.

Takas olmadığında çekirdeğin, ayrılmış ama nadiren kullanılan belleği koyacak bir yeri yoktur; bu yüzden onu önbellekten almak zorunda kalır.

Düzeltme

Sunucu önyükleme betiği artık her sunucu açıldığında ya da onarıldığında düşük swappiness değerine (10) sahip bir 2 GB takas dosyası oluşturuyor. Düşük swappiness, çekirdeğin çalışma belleğini yine RAM'de tutmayı tercih ettiği, ama nadiren dokunulan sayfaların program kodunu önbellekten zorla atmak yerine diske taşınabildiği anlamına gelir. Bunu iki üretim sunucusuna ve staging'e canlı olarak uyguladık; dağıtım hattı da her üretim dağıtımında önyükleme betiğini yeniden yayınlıyor, böylece değiştirilen bir sunucu da bunu alıyor.

Bizi daha çok endişelendiren kısım: sağlıksız sunucu yerinde kaldı

Sunucu grubumuz EC2 sağlık kontrollerini kullanıyordu ("makine çalışıyor mu?"), yük dengeleyici sağlık kontrollerini değil ("isteklere yanıt veriyor mu?"). Yani yük dengeleyicinin pes ettiği bir sunucu, grup açısından hâlâ sağlıklıydı. Asla değiştirilmezdi. Biri fark edip diğerini yeniden başlatana kadar üretim sessizce tek bir sunucuda çalışmaya devam ederdi.

Grubu yük dengeleyici sağlık kontrollerine geçirmek bariz çözüm gibi görünür, ama bizim için kolay değil: bir dağıtım sırasında sunucular, dengeleyicinin onları boşaltması için bilerek sağlık uç noktalarına hata yanıtı verir (bkz. dağıtımları sıfır 502'ye nasıl indirdik). Bu sinyale göre sunucu değiştiren bir grup, her dağıtımın ortasında sunucuları değiştirirdi.

Bu yüzden şimdilik dağıtım kontrol listemize bir adım ekledik: her dağıtımdan sonra, yalnızca dağıtım işinin geçip geçmediğine değil, yük dengeleyicideki her hedefin sağlığına bakın. Bir sunucuya giden komutlar "Pending" durumunda bekliyorsa, thrashing yapıyordur: yeniden başlatın; zaten rotasyon dışındadır.

Bundan çıkardıklarımız

• "Çökmemek" "sağlıklı" demek değildir. Thrashing hiçbir hata üretmez; yalnızca makinenin yanıt vermeyi bıraktığı kadar aşırı bir yavaşlık üretir.
• Küçük sunucuların takasa ihtiyacı vardır. Düşük swappiness ile bile küçük bir takas, çekirdeğe soğuk belleği koyacak bir yer verir.
• Makineden fazla toplanan bellek limitleri bir bahistir. Bazen kaybedersiniz. Ne zaman bahis oynadığınızı bilin.
• Otomatik ölçeklendirmenizin hangi sağlık kontrolüne güvendiğini bilin. Yalnızca "VM açık mı?" diye soran bir sağlık kontrolü, çalışmayı bırakmış bir sunucuyu değiştirmez.