Linux Sunucularda OOM Killer ve Bellek Sızıntısı Analizi

Son Güncelleme: Haziran 2026

OOM Killer, Linux sunucularda bellek yetersizliği oluştuğunda sistemi tamamen kilitlenmekten korumak için devreye giren çekirdek mekanizmasıdır. Özellikle VPS, VDS, hosting, veritabanı ve uygulama sunucularında bellek tüketimini doğru analiz etmek, kesintisiz hizmet ve performans için kritik öneme sahiptir.

Bu rehberde OOM Killer’ın nasıl çalıştığını, bellek sızıntısı (memory leak) belirtilerini, log analizini, süreç bazlı bellek kullanımını ve pratik önleme yöntemlerini adım adım inceleyeceğiz.

İçindekiler

• OOM Killer Nedir?
• OOM Killer Nasıl Çalışır?
• Belirtiler ve Log Analizi
• Bellek Kullanımını Ölçmek
• Bellek Sızıntısı Analizi
• OOM Önleme Yöntemleri
• Uygulama Bazlı İpuçları
• Örnek Müdahale Planı
• Sıkça Sorulan Sorular
• Sonuç

OOM Killer Nedir?

OOM Killer, İngilizce Out of Memory Killer ifadesinin kısaltmasıdır. Türkçeye “bellek yetersizliği sonlandırıcısı” olarak çevrilebilir. Linux çekirdeği, fiziksel RAM ve kullanılabilir takas alanı (swap) kritik seviyeye düştüğünde bazı süreçleri sonlandırarak sistemin tamamen yanıt vermez hale gelmesini engellemeye çalışır.

Bir sunucuda çalışan web sunucusu, veritabanı, PHP-FPM havuzu, Node.js servisi, Java uygulaması veya yedekleme işlemi beklenenden fazla bellek tüketebilir. Bu durumda Linux çekirdeği tüm sistemi kapatmak yerine, en uygun gördüğü süreci öldürür. Kullanıcı tarafında bu olay çoğu zaman “site düştü”, “veritabanı kapanmış”, “uygulama kendiliğinden restart olmuş” veya “502 Bad Gateway hatası alıyorum” şeklinde fark edilir.

OOM Killer tek başına bir hata değil, genellikle altta yatan kapasite planlama, yanlış servis yapılandırması, bellek sızıntısı veya trafik artışı probleminin sonucudur. Bu nedenle yalnızca öldürülen servisi yeniden başlatmak kalıcı çözüm sağlamaz; bellek tüketiminin neden arttığı analiz edilmelidir.

OOM Killer Nasıl Çalışır?

Linux çekirdeği, bellek baskısı oluştuğunda her süreç için bir risk puanı hesaplar. Bu puan genellikle oom_score olarak görülür. Puan ne kadar yüksekse, ilgili sürecin OOM durumunda sonlandırılma ihtimali o kadar fazladır.

oom_score ve oom_score_adj Mantığı

/proc dosya sistemi altında her sürecin OOM ile ilişkili değerleri incelenebilir. Örneğin bir sürecin PID değeri 1234 ise aşağıdaki dosyalar kontrol edilebilir:

cat /proc/1234/oom_score
cat /proc/1234/oom_score_adj

oom_score çekirdeğin hesapladığı anlık riski gösterirken, oom_score_adj yöneticinin bu sürecin öldürülme olasılığını artırmak veya azaltmak için kullanabileceği ayardır. Bu değer -1000 ile 1000 arasında olabilir. -1000 değeri süreci OOM Killer’dan pratikte korur; 1000 ise süreci daha kolay hedef haline getirir.

Hangi Süreçler Daha Risklidir?

• Yüksek bellek kullanan süreçler: Büyük veritabanı işlemleri, raporlama servisleri, import ve export işleri daha yüksek risk taşır.
• Çok sayıda worker açan servisler: Yanlış yapılandırılmış PHP-FPM, Apache veya kuyruk işleyicileri belleği hızla tüketebilir.
• Bellek limiti olmayan uygulamalar: Node.js, Java, Python ve PHP uygulamaları limitlenmediğinde beklenenden fazla RAM kullanabilir.
• Yoğun trafik alan web siteleri: Ani trafik artışı, her istek için yeni süreç veya thread oluşuyorsa OOM riskini yükseltir.

Belirtiler ve Log Analizi

OOM olayları bazen belirgin bir hata mesajı vermeden gerçekleşir. Bir servis kapanır, süreç kaybolur veya sistem birkaç saniye boyunca yanıt vermeyebilir. Bu nedenle ilk adım her zaman logları kontrol etmektir.

journalctl ile OOM Kayıtlarını Bulma

Systemd kullanan Linux dağıtımlarında journalctl ile çekirdek logları incelenebilir:

journalctl -k | grep -i "out of memory"
journalctl -k | grep -i "killed process"
journalctl -k --since "24 hours ago" | grep -Ei "oom|killed process|out of memory"

Bu komutlar, son 24 saat içinde OOM Killer tarafından sonlandırılan süreçleri bulmak için pratik bir başlangıç sağlar. Loglarda genellikle süreç adı, PID, bellek tüketimi ve öldürülme nedeni görülebilir.

dmesg ile Çekirdek Mesajlarını İnceleme

dmesg, çekirdek mesajlarını hızlıca görmek için kullanılır:

dmesg -T | grep -Ei "oom|killed process|out of memory"

-T parametresi zaman damgalarını okunabilir biçime çevirir. Böylece OOM olayının tam olarak hangi saatte yaşandığı tespit edilebilir ve aynı zaman aralığındaki web, veritabanı veya uygulama loglarıyla karşılaştırılabilir.

Tipik OOM Log Örneği

Out of memory: Killed process 24567 (php-fpm) total-vm:2048000kB, anon-rss:850000kB, file-rss:0kB, shmem-rss:0kB

Bu örnekte php-fpm süreci öldürülmüştür. anon-rss değeri, sürecin gerçek RAM kullanımını anlamak için önemlidir. Eğer aynı servis tekrar tekrar öldürülüyorsa, ilgili servis yapılandırması veya uygulama kodu detaylı incelenmelidir.

Bellek Kullanımını Ölçmek

OOM analizinde yalnızca toplam RAM miktarına bakmak yeterli değildir. Kullanılabilir bellek, cache, swap, süreç sayısı, servis limitleri ve anlık yük birlikte değerlendirilmelidir.

free Komutu ile Genel Durum

free -h

free -h komutu toplam, kullanılan, boş, cache ve kullanılabilir bellek değerlerini gösterir. Linux sistemlerde “used” değerinin yüksek görünmesi her zaman problem değildir; çünkü çekirdek boş belleği disk önbelleği için kullanabilir. Daha doğru yorum için available sütununa bakılmalıdır.

ps ile En Çok Bellek Kullanan Süreçler

ps aux --sort=-%mem | head -n 15

Bu komut, bellek kullanımına göre en yüksek süreçleri listeler. Ani artış yaşayan servisleri tespit etmek için belirli aralıklarla çalıştırılabilir.

smem ile PSS Değeri

smem, paylaşılan bellek kullanımını daha doğru yorumlamak için PSS (Proportional Set Size) değerini gösterir. Özellikle çok sayıda worker kullanan servislerde RSS değerleri yanıltıcı olabilir.

apt update
apt install smem -y
smem -tk | sort -nr -k 7 | head -n 20

Temel Bellek Metrikleri

Bellek Sızıntısı Analizi

Bellek sızıntısı, bir uygulamanın artık ihtiyaç duymadığı belleği işletim sistemine geri bırakmaması durumudur. Kısa süreli testlerde fark edilmeyebilir; ancak saatler veya günler içinde süreç belleği sürekli artar ve sonunda OOM Killer devreye girebilir.

Belirgin İşaretler

• Sürekli artan RSS: Servis yeniden başlatılana kadar bellek kullanımı düzenli olarak yükselir.
• Trafikten bağımsız artış: Ziyaretçi veya işlem sayısı düşük olsa bile bellek büyümeye devam eder.
• Tekrarlayan servis çökmesi: Aynı süreç belirli aralıklarla OOM nedeniyle kapanır.
• Yavaşlayan yanıt süreleri: Swap kullanımı arttıkça uygulama gecikmeleri belirginleşir.

Basit İzleme Döngüsü

Aşağıdaki örnek, belirli bir sürecin bellek kullanımını periyodik olarak izlemek için kullanılabilir:

while true; do
  date
  ps -o pid,ppid,cmd,%mem,rss,vsz -p 1234
  sleep 60
done

PID değişebileceği için servis adına göre takip yapmak çoğu zaman daha kullanışlıdır:

while true; do
  date
  ps aux | grep -E "php-fpm|node|java" | grep -v grep | sort -nr -k 4 | head
  sleep 60
done

Grafiksel İzleme Neden Gereklidir?

Komut satırı anlık teşhis için yeterli olsa da bellek sızıntısını anlamak için zaman serisi verisi gerekir. RAM, swap, süreç sayısı, CPU, disk I/O ve ağ trafiği birlikte grafiklenmelidir. Böylece örneğin her gece çalışan bir raporlama görevinin bellek tüketimini artırdığı veya belirli endpoint çağrılarından sonra worker süreçlerinin büyüdüğü görülebilir.

OOM Önleme Yöntemleri

OOM olaylarını azaltmak için tek bir ayar yeterli değildir. Doğru yaklaşım; servis limitleri, uygulama optimizasyonu, swap yönetimi, izleme ve kapasite planlamasını birlikte uygulamaktır.

Servis Başına Bellek Limiti Tanımlama

Systemd servislerinde MemoryMax ile bellek limiti belirlenebilir. Bu yöntem, tek bir servisin tüm sunucuyu tüketmesini engeller.

systemctl edit my-app.service

[Service]
MemoryMax=1G
Restart=on-failure
RestartSec=5

Değişiklikten sonra servis yapılandırması yeniden yüklenmelidir:

systemctl daemon-reload
systemctl restart my-app.service

Swap Alanını Doğru Kullanma

Swap, RAM’in yerine geçmez; ancak ani bellek sıçramalarında sistemin tamamen kilitlenmesini önleyebilir. Çok düşük RAM’e sahip sunucularda kontrollü swap alanı faydalı olabilir. Fakat yoğun swap kullanımı disk performansını düşürebilir.

swapon --show
free -h

Worker Sayılarını Sınırlandırma

PHP-FPM, Apache, Nginx worker, queue worker ve uygulama süreçleri sınırsız büyümemelidir. Örneğin her PHP-FPM worker ortalama 80 MB bellek kullanıyorsa, 40 worker yaklaşık 3.2 GB RAM tüketebilir. Sunucuda veritabanı da çalışıyorsa bu değer OOM için yeterli olabilir.

Uygulama Bazlı İpuçları

OOM problemleri çoğu zaman uygulama katmanında başlar. Sunucu tarafında önlem almak önemlidir; ancak kod, framework ve çalışma zamanı ayarları da gözden geçirilmelidir.

PHP ve Laravel Uygulamaları

PHP tarafında memory_limit, her script için üst sınır belirler. Laravel gibi framework kullanan projelerde queue worker süreçleri uzun süre çalıştığı için bellek sızıntıları daha kolay ortaya çıkar. Worker süreçlerini belirli iş sayısından sonra yeniden başlatmak etkili bir yöntemdir.

php artisan queue:work --max-jobs=500 --max-time=3600

Ayrıca büyük Excel, CSV veya görsel işleme operasyonlarında verinin tamamını belleğe almak yerine parça parça işlemek daha sağlıklıdır.

Node.js Uygulamaları

Node.js uygulamalarında heap limiti açıkça belirlenebilir. Bellek tüketimi kontrol altına alınmadığında V8 motoru yüksek bellek kullanabilir.

node --max-old-space-size=1024 app.js

PM2 gibi süreç yöneticileri kullanılıyorsa bellek eşiğine göre otomatik restart uygulanabilir:

pm2 start app.js --max-memory-restart 1G

Veritabanı Sunucuları

MySQL, MariaDB veya PostgreSQL gibi veritabanlarında bellek ayarları toplam RAM’e göre planlanmalıdır. Buffer, cache, bağlantı sayısı ve geçici tablo ayarları yanlış yapılandırıldığında veritabanı tek başına sunucuyu OOM noktasına taşıyabilir. Uygulama ve veritabanı aynı sunucuda çalışıyorsa daha dikkatli limitleme yapılmalıdır.

Yoğun veritabanı ve web trafiği olan projelerde kaynak izolasyonu için Türkiye VDS Sunucu veya daha yüksek kaynak gerektiren senaryolarda Kiralık Sunucu tercih edilebilir.

Örnek Müdahale Planı

Bir üretim sunucusunda OOM yaşandığında panikle yalnızca servis restart etmek yerine sistematik ilerlemek gerekir. Aşağıdaki plan, hızlı teşhis ve kalıcı çözüm için kullanılabilir.

1. Olay saatini belirleyin: Kullanıcı şikayetleri, izleme alarmları ve servis loglarıyla kesinti zamanını netleştirin.
2. Çekirdek loglarını kontrol edin: journalctl ve dmesg ile OOM mesajlarını bulun.
3. Öldürülen süreci tespit edin: Hangi servis, hangi PID ve ne kadar bellek ile sonlandırılmış inceleyin.
4. Servis loglarıyla eşleştirin: Aynı dakikada web isteği, cron, import, backup veya kampanya trafiği var mı kontrol edin.
5. Anlık kaynak durumunu ölçün: free, ps, top, smem ve disk I/O değerlerini inceleyin.
6. Geçici önlem alın: Gerekirse worker sayısını düşürün, problemli cron görevini durdurun veya servisi kontrollü yeniden başlatın.
7. Kalıcı limitler uygulayın: Systemd, PHP-FPM, Node.js, Java veya veritabanı ayarlarında kaynak sınırlarını tanımlayın.
8. İzleme ekleyin: RAM, swap, süreç sayısı ve servis özel metrikleri için alarm oluşturun.

Özellikle yedekleme ve büyük dosya işleme görevleri bellek tüketimini artırabilir. Kritik projelerde düzenli yedekleme mimarisi için Yedekleme Hizmeti değerlendirilmelidir. Web projeleri için başlangıç seviyesinde daha yönetilebilir bir yapı gerekiyorsa Linux Hosting çözümleri de uygun olabilir.

Sıkça Sorulan Sorular

Sonuç

Linux OOM Killer, sunucuyu tamamen kilitlenmekten koruyan önemli bir güvenlik mekanizmasıdır; ancak sık görülmesi ciddi bir kaynak veya yapılandırma problemine işaret eder. Kalıcı çözüm için log analizi, süreç bazlı bellek ölçümü, servis limitleri, uygulama optimizasyonu ve düzenli izleme birlikte uygulanmalıdır.

Web siteniz, uygulamanız veya veritabanınız büyüdükçe bellek yönetimi daha kritik hale gelir. Kaynak izolasyonu, yüksek performans ve ölçeklenebilir altyapı için Corelux Sanal Sunucu, Bulut Sunucu ve Kiralık Sunucu çözümlerini değerlendirebilir; projenize uygun altyapı ile OOM riskini en aza indirebilirsiniz.