Sunucu Çökmelerine Karşı OOM Killer Ayarları ve Optimizasyonu

Sunucu ortamlarında bellek yetersizliği, sistem çökmelerine yol açan en yaygın sorunlardan biridir. Linux tabanlı sunucularda Out-of-Memory (OOM) Killer mekanizması, bu tür durumlarda kritik bir rol oynar. OOM Killer, sistem belleğinin tükenmeye başladığı anlarda bellek tüketen süreçleri otomatik olarak sonlandırarak sistemin tamamen kilitlenmesini önler. Bu makalede, OOM Killer’ın çalışma prensiplerini inceleyecek, ayarlarını yapılandırarak sunucu stabilizasyonunu sağlayacak pratik adımları ele alacak ve optimizasyon stratejileriyle uzun vadeli performans iyileştirmeleri sunacağız. Kurumsal sunucu yöneticileri için bu rehber, proaktif yaklaşımlarla downtime’ı minimize etmeyi hedeflemektedir.

OOM Killer’ın Çalışma Prensipleri

Linux çekirdeğinde yerleşik olan OOM Killer, fiziksel ve swap belleğinin tamamen dolması durumunda devreye girer. Sistem, yeni bellek tahsis taleplerini karşılayamadığında oom-killer tetiklenir ve heuristik bir puanlama sistemiyle en uygun süreci seçerek sonlandırır. Bu puanlama, süreçlerin RSS (Resident Set Size) belleği kullanımına, swap kullanımına ve nice değerlerine göre hesaplanır. Örneğin, root kullanıcısı altında çalışan süreçler daha yüksek oom_score sahip olur ve öncelikli olarak hedeflenir.

OOM Killer’ın etkinliğini anlamak için /proc dizinini incelemek faydalıdır. Her süreç için /proc/[PID]/oom_score ve /proc/[PID]/oom_score_adj dosyaları mevcut olup, bu değerler süreçlerin öldürülme olasılığını belirler. oom_score_adj değeri -1000 ile 1000 arasında ayarlanabilir; negatif değerler süreci korumaya alır, pozitifler ise öldürülme riskini artırır. Bu mekanizmayı izlemek, sunucu loglarında “Out of memory: Kill process” mesajlarını kernel ring buffer’ından (dmesg komutuyla) takip etmekle başlar. Pratikte, yüksek trafikli web sunucularında veritabanı süreçlerinin oom_score’larını düşürerek önceliklendirme yapılabilir.

OOM Killer Ayarlarını Yapılandırma

vm.overcommit_memory Parametresi

vm.overcommit_memory, bellek tahsis politikalarını belirleyen temel parametredir. Varsayılan değer 0’dır ve heuristik overcommit uygular. Değeri 1 olarak ayarlamak, her tahsisi kabul eder ancak OOM riskini artırır. Kurumsal ortamlarda önerilen 2 değeri, sıkı overcommit’i etkinleştirir ve yalnızca fiziksel belleğin iki katı kadar tahsis yapılmasını sağlar. Ayarlamak için /etc/sysctl.conf dosyasına “vm.overcommit_memory = 2” satırını ekleyin, ardından sysctl -p ile uygulayın. Bu değişiklik, bellek sızıntılarını erken tespit ederek sunucu stabilitesini artırır. Test ortamında, bu ayarı uyguladıktan sonra stress-ng aracıyla bellek yükü simüle ederek etkinliği doğrulayın.

vm.oom_kill_allocating_task ve Diğer Ayarlar

vm.oom_kill_allocating_task=1 olarak ayarlandığında, OOM durumunda yalnızca bellek talep eden süreç öldürülür, böylece zincirleme etkiler önlenir. /etc/sysctl.conf’a “vm.oom_dump_tasks=1” ekleyerek detaylı loglar alınır. Ayrıca, vm.min_free_kbytes parametresiyle minimum serbest bellek rezervini belirleyin; örneğin 65536 (64MB) değeri, yüksek yük altında killer’ı erken tetikler. Uygulama adımları: sysctl -w vm.oom_kill_allocating_task=1 ile anlık test yapın, kalıcılaştırmak için conf dosyasını güncelleyin. Bu ayarlar, containerized ortamlarda (Docker/Kubernetes) özellikle faydalıdır, zira pod’lar arası izolasyonu güçlendirir.

Süreç Bazlı oom_score_adj Optimizasyonu

Her süreç için /proc/[PID]/oom_score_adj dosyasını echo ile ayarlayın; örneğin kritik veritabanı için echo -500 > /proc/[PID]/oom_score_adj. Sistemd servislerinde bu, unit dosyasına OOMScoreAdjust=-500 ekleyerek kalıcı hale getirilir. Yeniden yükleme için systemctl daemon-reload ve restart yapın. Bu yöntem, Apache veya Nginx gibi web sunucularında önemsiz worker süreçlerini koruyarak ana servisleri güvence altına alır. İzleme için bir cron job ile ps aux | awk ‘{print $2}’ | xargs -I {} cat /proc/{}/oom_score_adj >> /var/log/oom_monitor.log oluşturun, böylece periyodik raporlama sağlanır.

Sunucu Optimizasyonu ve İzleme Stratejileri

OOM Killer ayarlarının yanı sıra, bellek optimizasyonu için swap kullanımını sınırlayın ve transparent huge pages’i etkinleştirin (echo always > /sys/kernel/mm/transparent_hugepage/enabled). EarlyOOM aracını yükleyerek kullanıcı alanı killer’ı entegre edin; systemd servisleri için systemd-oomd kullanın ki modern kernel’lerde (5.15+) daha hassas kontrol sağlasın. Pratik takeaway: Bellek kullanımını Prometheus + Node Exporter ile izleyin, alert kuralları tanımlayın (örneğin mem_available_bytes < 10% ise uyarı). Bu entegrasyon, proaktif müdahale imkanı verir.

Swap’ı optimize etmek için swappiness=10 olarak ayarlayın (/etc/sysctl.conf’a vm.swappiness=10 ekleyin), böylece fiziksel belleğe öncelik verilir. Uygulamalarda bellek limitleri belirleyin; örneğin ulimit -v 1048576 ile her kullanıcıyı 1GB ile sınırlayın. Container’larda cgroup v2 ile memory.max kullanın. Bu stratejiler birleştiğinde, sunucu çökmeleri %90 oranında azalır ve uptime artar. Düzenli bakım için aylık sysctl ayarlarını doğrulayın ve logları analiz edin.

Sonuç olarak, OOM Killer ayarlarını doğru yapılandırarak ve optimizasyon teknikleri uygulayarak sunucularınızı yüksek erişilebilirlik seviyesine taşıyabilirsiniz. Bu adımları kurumsal politikalarınıza entegre edin, test ortamlarında doğrulayın ve ekip eğitimleriyle pekiştirin. Sürekli izleme ve ince ayarlarla, beklenmedik çökmeleri tarihe gömecek, iş sürekliliğinizi güvence altına alacaksınız.