VPS için Linux OOM killer ayarlaması

Linux OOM killer, bellek tükendiğinde çekirdeğin son çare olarak başvurduğu bir mekanizmadır: sistemi ayakta tutmak için bir işlem seçer ve onu sonlandırır. RAM'in kısıtlı olduğu ve geri dönebilecek bir yerin bulunmadığı bir VPS'de, varsayılan seçim genellikle yanlış olandır. Veritabanınız sonlandırılır, uzun süredir çalışan bir iş parçacığı hayatta kalır ve siz de bunun nedenini bulmaya çalışırsınız. Bu kılavuz, OOM killer'ın işlemleri nasıl puanladığını, bu puanlamayı kritik hizmetlerinize nasıl yönlendirebileceğinizi ve tek bir kaçak işlemin sistemin geri kalanını da beraberinde çökertmemesi için cgroup'ları nasıl kullanabileceğinizi ele almaktadır.

OOM killer kurbanını nasıl seçer?

Çekirdek, sayfa önbelleği temizleme veya takas yoluyla yeterli bellek geri kazanamadığında, OOM katilini çağırır. Her işlemin oom_score 0 ile 1000 arasında bir puana sahiptir; bu puan çoğunlukla Resident Set Size (RSS) ve takas kullanımından türetilir. En yüksek puana sahip işlem bir SIGKILL alır.

RSS, hesaplamada baskındır; bu nedenle, sonlandırma neredeyse her zaman en fazla bellek tüketen işleme uygulanır. Bu genellikle veritabanınız, uygulama sunucunuz veya en yararlı işi yapan uzun ömürlü herhangi bir işlemdir. Tahsisi fiilen tetikleyen işlem, yani "çağırıcı", nadiren sonlandırılan işlem olur.

Ayrık tutmanız gereken iki tür OOM olayı vardır:

• Global OOM: ana bilgisayar (veya VPS'nizin tamamı) RAM ve takas alanı tükenmiştir. Çekirdek her işlemi tarar ve en yüksek puanı alan işlemi sonlandırır.
• Cgroup OOM: belirli bir cgroup bellek sınırına ulaşmıştır. Sistemdeki diğer bölümlerde boş bellek olsa bile, çekirdek yalnızca o cgroup içindeki işlemleri sonlandırır.

Systemd birim sınırlarını yapılandırdıysanız veya konteyner çalıştırıyorsanız, OOM olaylarınızın çoğu cgroup OOM'ları olacaktır. Bu iyi bir şeydir: etki alanı sınırlıdır.

Kilitlenmeden önce bellek baskısını tespit etme

OOM olayları neredeyse hiçbir zaman ani olarak gerçekleşmez. Genellikle önce artan bir baskı dönemi olur ve izlemenin amacı bu dönemde bunu yakalamaktır.

free -h size sistem görünümünü sunar. Önemli olan sütun available, free: geri kazanılabilir sayfa önbelleğini hesaba katar ve takas yapmadan gerçekte ne kadar bellek ayırabileceğinizi gösterir. MemAvailable , en yüksek yükte MemTotal yaklaşık yüzde 10 ila 15 arasında tutun.

İşlem başına atıf için RSS'ye göre sıralayın:

ps aux --sort=-%mem | head -10

Veya htop ve RES. Burada gördüğünüz değerler doğrudan çekirdeğin puanlamasına girer, bu nedenle en üstteki girdiler en olası OOM hedefleridir.

4.20 ve daha yeni çekirdeklerde, Pressure Stall Information, izlemeye dahil etmeye değer bir erken uyarı sistemidir:

cat /proc/pressure/memory

Bu some avg10 Şekil, son on saniye içinde en az bir görevin bellek beklerken durduğu sürenin yüzdesidir. Yüzde 5'in altında olması iyidir. Sürekli olarak yüzde 10'un üzerinde değerler, sistemin gerçek zamanını bellek geri kazanımı için harcadığı ve bir OOM sonlandırmasının olası olduğu anlamına gelir.

Swap thrashing, vmstat 1 sıfır olmayan si ve so sütunlarında zaman içinde devam eden değerler olarak görünür. Az miktarda yerleşik takas zararsızdır. Sürekli takas girişi ve takas çıkışı ise zararlıdır.

Oom_score_adj ile kritik süreçleri koruma

Çekirdeğin hesapladığı puan, -1000 (bağışıklık) ile +1000 (önce beni öldür) arasında bir ölçekte oom_score_adj, -1000 (bağışık) ile +1000 (önce beni öldür) arasında bir ölçekte ayarlanabilir. Ayarlama, doğrudan nihai puana eklenir.

Çalışan bir sürece karşı tek seferlik bir değişiklik için:

echo -500 | sudo tee /proc/$(pidof sshd)/oom_score_adj

Yeniden başlatmalarda kalıcı olmasını istediğiniz her şey için, bunu systemd biriminde ayarlayın. Bu, sshd, veritabanınız ve kaybetmeyi göze alamayacağınız diğer her şey için doğru yerdir:

[Service]
OOMScoreAdjust=-900

Başlangıç için mantıklı varsayılan değerler:

• sshd: -1000. Bir bellek krizi sırasında uzaktan erişimi kaybederseniz, kurtarma işlemi çok daha zor hale gelir.
• MySQL, PostgreSQL, Redis: -800 ila -900. Gerçekten felaket niteliğinde bir durumda bunları tamamen dokunulmaz hale getirmeden güçlü koruma sağlar.
• Uygulama işçileri, toplu işler, cron görevleri: +100 ile +500 arası. Bunlar, veritabanınızdan ziyade sonlandırılmasını tercih edeceğiniz işlemlerdir.

Her şeyi -1000 olarak ayarlamayın. Hiçbir şey sonlandırılamazsa, çekirdek sonunda paniğe kapılır veya donar, ki bu daha kötüdür.

Cgroups ve systemd ile bellek sınırlama

Puanları ayarlamak, kimin sonlandırılacağını etkiler. Cgroups, genel sonlandırmanın gerçekleşip gerçekleşmeyeceğini etkiler. Her hizmete katı bir üst sınır vererek, tek bir işlemin tüm VPS'yi tüketmesine izin vermek yerine, bellek hatalarını tek bir cgroup'a yönlendirirsiniz.

Bir systemd birim dosyasında:

[Service]
MemoryHigh=400M
MemoryMax=512M
OOMPolicy=stop
Restart=on-failure
RestartSec=5s

MemoryHigh yumuşak bir kısıtlamadır: çekirdek, bu noktanın üzerindeki cgroup'tan sayfaları agresif bir şekilde geri alır, ancak hiçbir şeyi sonlandırmaz. MemoryMax sert bir üst sınırdır. Eğer cgroup bu sınırı aşarak bellek ayırmaya çalışırsa, çekirdek cgroup içindeki bir işlemi sonlandırır. Restart=on-failure hizmet hemen geri gelir.

cgroup v2'de (Ubuntu 22.04 ve sonrası, son Debian sürümleri, RHEL 9), memory.oom.group , geride yetim süreçler bırakmak yerine cgroup'taki tüm süreçleri bir arada sonlandırır. Yarı sonlandırılmış bir grubun hatalı davranacağı PHP-FPM havuzları gibi çoklu süreç hizmetleri için kullanışlıdır.

Uygulanmaya değer birkaç uygulamaya özgü not:

• PHP-FPM: pm = ondemand küçük VPS örneklerinde ayarlayın ve pm.max_children işçi başına ortalama RSS'ye göre ayarlayın, varsayılana göre değil. 2 GB'lık bir VPS üzerinde 4 GB'lık boşluk bırakılarak boyutlandırılmış bir havuz, ilk dolduğunda OOM hatası verecektir.
• Node.js: V8 yığınını --max-old-space-size=512 (MB cinsinden) ile sınırlayın. Aksi takdirde, çekirdek müdahale edene kadar Node sorunsuz bir şekilde büyüyecektir.
• MySQL ve PostgreSQL: innodb_buffer_pool_size ve shared_buffers işletim sistemi sayfa önbelleği, bağlantı belleği ve kutudaki diğer kiracılar için yeterli boş alan bırakmalıdır. Varsayılan ayarlar, özel bir sunucuyu varsayar.

OOM olayından sonra günlükleri okuma

OOM killer devreye girdiğinde, çekirdek ayrıntılı bir raporu halka tamponuna döker. Bunu şu komutla alabilirsiniz:

dmesg -T | grep -iE 'killed process|out of memory'
journalctl -k --grep='Out of memory'

Dikkatle okunması gereken blok, çağıran ile başlar ve kurban ile biter. Çekirdek, her işlemin RSS'si, takas kullanımı ve son oom_score_adj. Kontrol etmeye değer üç şey vardır:

• Kısıtlama. CONSTRAINT_NONE , genel bir OOM anlamına gelir, CONSTRAINT_MEMCG cgroup'un sınırına ulaştığı anlamına gelir. Her durumda çözüm farklıdır.
• Free swap. Eğer bu 0kBise, hem RAM hem de takas alanı tükenmiştir. Ya takas alanı ekleyin, MemoryMax ya da eşzamanlılığı azaltın.
• Mağdurun puanı diğer her şeye kıyasla. Eğer mağdurun puanı sonraki birkaç işlemden çok daha yüksek değilse, oom_score_adj değerleriniz yeterince işe yaramıyor demektir. Aradaki farkı artırın.

Özellikle cgroup OOM'ları için, kill sayacı memory.events cgroup içinde bulunur:

cat /sys/fs/cgroup/system.slice/mysql.service/memory.events

Artan oom_kill , hizmetin sınırına tekrar tekrar ulaştığı anlamına gelir. Bu, MemoryMax, iş yükünü analiz etmek veya hizmeti daha büyük bir plana taşımak için bir işarettir; onu bir döngü içinde yeniden başlatmaya devam etmek için değil.

Sonuç

OOM killer'ı ayarlamak, onu ortadan kaldırmakla ilgili değildir. Bellek tükendiğinde hangi işlemin bedelini ödeyeceğini kontrol etmek ve bu durum meydana geldiğinde etkilenme alanını daraltmakla ilgilidir. Üretimde geçerli olan kural şudur:

• Kaybetmeyi göze alamayacağınız hizmetleri, özellikle sshd ve veritabanlarınızı skor koruması altına alın.
• Diğer her şeyi MemoryMax ile sınırlayın, böylece tek bir kaçak işlem, kesintiye neden olmak yerine tek bir yeniden başlatma ile sonuçlansın.
• PSI'yi izleyin ve MemAvailable sonrasında dmesg sonrasında size durumu bildirmesini beklemeyin.
• RAM'in yüzde 15 ila 20'sini yedek olarak bırakın. Ayarlamalar, iş yükü için çok küçük olan bir VPS'yi telafi edemez.

Bellek baskınız yapılandırılabilir değil de yapısal ise, daha fazla RAM'e veya daha hızlı takas destekli depolamaya ihtiyacınız vardır. FDC Servers'ın VPS planları, NVMe depolamalı AMD EPYC üzerinde çalışır; bu da takas destekli okumaları yeterince hızlı tutar, böylece kısa süreli bellek patlamaları sistemin kapanmasına yol açmaz.