Bir Linux sunucusunda bellek tükenirse, OOM killer devreye girer ve RAM'i boşaltmak için süreçleri sonlandırır. Varsayılan olarak, süreçleri OOM puanına göre seçer; bu puan bellek kullanımı ve çalışma davranışını yansıtır. Ancak tüm süreçler eşit değildir — bir veritabanını veya web ön ucunu sonlandırmak, bir batch işini durdurmaktan daha fazla zarar verebilir. İzleme yığınlarında Prometheus'un öldürülürken düşük öncelikli bir log toplayıcının hayatta kalmasını gördüm; bu da sonrası analizini zorlaştırdı.
İyi haber şu: bu kararı etkileyebilirsiniz. Her süreç, öldürülme olasılığını değiştiren bir oom_score_adj değeri sahiptir. Bu değer -1000 (en az olasılık) ile +1000 (en yüksek olasılık) arasında değişir. Negatif bir değer süreci korur; pozitif bir değer onu daha harcanabilir kılar.
Bir sürecin mevcut OOM puanı ve ayarını görmek için şu komutları kullanın:
cat /proc/<PID>/oom_score
cat /proc/<PID>/oom_score_adjÖrneğin, nginx (PID 1234) için oom_score 300 ve oom_score_adj 0 ise, etkili puanı 300 olur. Eğer oom_score_adj'yi -500 olarak ayarlarım, çekirdek onu -200 puanlıymış gibi davranır — bu da onu öldürülme olasılığını çok düşürür.
Bu değeri iki şekilde ayarlayabilirsiniz. Çalışan bir süreç için:
echo -500 > /proc/1234/oom_score_adjBu komut root yetkisi gerektirir ve hemen etkisini gösterir. Ancak yeniden başlatmada kalıcı olmaz. Kalıcı hale getirmek için en iyi yöntem systemd üzerindendir. Servis dosyanıza şunu ekleyin:
[Service]
OOMScoreAdjust=-500Sonra yeniden yükleyip yeniden başlatın:
systemctl daemon-reload
systemctl restart nginxBu yöntemi yük dengeleyicilerim ve API geçitlerimde kullanırım — burada duraklama hızla yayılır. Arka plan işçileri veya log taşıyıcıları için ise +200 gibi pozitif bir ayar yaparım; böylece bellek sıkışıntısında önce onlar hedef olur.
Önemli: oom_score_adj değerini -1000 olarak ayarlamaktan kaçının, mutlak olarak emin olmadığınız sürece. Bu, çekirdeğe süreci asla öldürmemesini söyler; eğer süreç gerçekten davranış bozukluğu gösterirse, sistem kilitlenebilir. Bir hata ayıklama aracısını -1000 olarak ayarladım ve bellek sızıntısı yaşadığında sistemden çıkış yoktu, şebekeyi çekmek zorunda kaldım.
Ayrıca unutmayın: oom_score_adj, gerçek bellek kullanımını değiştirmez — sadece öldürme önceliğini değiştirir. Yüksek RSS ve negatif ayarlı bir süreç hâlâ bellek baskısı yaratabilir; sadece ilk sonlandırılmayacaktır.
Yoğun bir sistemde ayarlama yapacaksanız, stres testleri sırasında hangi süreçlerin öldürüldüğünü önce gözlemleyin. Bellek baskısı tetikledikten sonra dmesg | grep -i kill komutunu çalıştırarak OOM killer'ın hangi süreçleri seçtiğini görün. Daha sonra ona göre ayarlayın.
Kernel CPU hata ayıklama kılavuzumda önce bahsettiğim gibi, bu tür düşük seviyeli davranışları anlamak, sadece şeyler bozulduğunda tepki vermek yerine daha dayanıklı sistemler kurmanıza yardımcı olur.
Çoğu üretim hizmeti için kritik yollar için -500, harcanabilir olanlar için +100 ile +300 arasında başlarım. Yük altında izler, ayarlar ve doğrularım. Bu küçük bir ayar olsa da, çekirdek hayatı veya ölümü kararlar vermeye başladığında sizi kontrolün içinde tutar.
Kapak görseli: USDAgov · PDM (Openverse / kamu malı) · https://www.flickr.com/photos/41284017@N08/7644752188