Linux Sunucularda OOM Killer: Bellek Tükenmesini Tanılama ve Önleme

Son Güncelleme: Eylül 2026

Bir web sitesi aniden yanıt vermemeye başladığında veya veritabanı hizmeti beklenmedik biçimde kapandığında neden OOM Killer olabilir. Linux sunucularda bellek tükenmesi belirtilerini doğru okumak, hangi sürecin sonlandırıldığını bulmak ve tekrarı önlemek için yalnızca toplam RAM kullanımına değil, servis sınırlarına ve bellek baskısına da bakmak gerekir.

İçindekiler

• OOM Killer Nedir?
• Belirtiler ve Yaygın Nedenler
• OOM Olayı Nasıl Tanılanır?
• Servis Bazında Bellek Sınırları
• Bellek Tükenmesini Önleme Stratejileri
• Örnek Uygulama Senaryosu
• Sıkça Sorulan Sorular
• Sonuç

OOM Killer Nedir?

OOM, Out of Memory (bellek yetersizliği) ifadesinin kısaltmasıdır. Linux çekirdeği, bir bellek isteğini karşılamak için yeterli kaynak sağlayamadığında uygun gördüğü süreci sonlandırarak belleği geri kazanmaya çalışabilir. Bu mekanizma, bütün sunucunun yanıtsız kalması yerine belirli bir iş yükünün kesintiye uğramasına yol açabilir. Ancak sonlandırılan süreç veritabanı veya uygulama işçisi ise hizmet yine erişilemez hâle gelebilir.

Sistem genelinde OOM ile servis sınırında OOM farklıdır

Sistem genelinde OOM, sunucunun kullanabileceği bellek kaynaklarının baskı altında olmasıyla ilişkilidir. Kontrol grubu veya cgroup (kaynak denetim grubu) kaynaklı OOM ise belirli bir servisin kendi bellek sınırına ulaşmasıyla oluşabilir. İkinci durumda sunucuda boş RAM görülmesi, ilgili servisin sınırını aşmadığı anlamına gelmez. Özellikle VPS ve VDS üzerinde uygulama, veritabanı ve arka plan işlerini ayrı servislerde çalıştıran ekipler için bu ayrım tanılamanın ilk adımıdır.

Hangi süreç seçilir?

Çekirdek, OOM koşullarında sonlandırılabilecek süreçleri değerlendirirken bellek kullanımını ve süreç için belirlenmiş oom_score_adj ayarını dikkate alır. /proc/PID/oom_score dosyasındaki yüksek değer, ilgili sürecin seçilme olasılığının daha yüksek olduğuna işaret eder; bu değer olayın gerçekleşeceğine ilişkin kesin bir tahmin değildir. oom_score_adj ayarını aşırı düşürerek birçok süreci korumaya çalışmak, sonlandırılabilecek uygun süreç bırakmayabileceği için güvenli bir kapasite planının yerini tutmaz.

Belirtiler ve Yaygın Nedenler

OOM olayından önce yanıt süreleri uzayabilir; olay sonrasında ise bir servis yeniden başlayabilir veya tamamen durmuş görünebilir. Yalnızca uygulamanın verdiği hata koduna bakarak OOM tanısı koymak doğru değildir: aynı belirti yapılandırma hatası, ağ sorunu veya çöken bir bağımlılık yüzünden de ortaya çıkabilir.

• Ani trafik yükselişi: Eşzamanlı istek sayısı artınca uygulama işçilerinin toplam bellek tüketimi beklenenden hızlı büyüyebilir.
• Çok sayıda işçi süreci: Tek işçinin tüketimi makul görünse bile bütün işçilerin toplamı sunucu kapasitesini aşabilir.
• Büyük veri işlemleri: Rapor üretimi, görsel işleme veya toplu içe aktarma sırasında kısa süreli yüksek bellek gereksinimi oluşabilir.
• Bellek sızıntısı: Uygulama nesneleri ya da önbellek girdileri serbest bırakılmadığında kullanım zaman içinde sürekli yükselir.
• Yanlış servis sınırı: Uygulama için belirlenen üst sınır gerçek iş yüküne göre düşükse sistemin tamamı rahat görünürken servis OOM yaşayabilir.
• Birlikte çalışan hizmetler: Web sunucusu, veritabanı, kuyruk işçisi ve izleme araçları aynı RAM bütçesini paylaşır; her birini ayrı ayrı boyutlandırmak yeterli değildir.

Swap (takas alanı), bazı bellek sayfalarını depolama alanına taşıyarak kısa süreli baskıyı hafifletebilir. Fakat RAM yerine geçen eşdeğer hızda bir kaynak değildir. Sık kullanılan verilerin sürekli swap alanına taşınması uygulamayı belirgin biçimde yavaşlatabilir; swap varlığı OOM yaşanmayacağını da garanti etmez.

OOM Olayı Nasıl Tanılanır?

Önce olay zamanını ve sonlandırılan süreci bulun

Üretim ortamında rastgele servis yeniden başlatmadan önce kesintinin saatini not edin. Çekirdek günlüğünde OOM kayıtlarını aramak, hangi sürecin sonlandırıldığını ve olayın servis sınırıyla ilişkili olup olmadığını anlamaya yardımcı olur. Günlük saklama ayarları ve sunucunun yeniden başlatılmış olması, eski kayıtların bulunabilirliğini etkileyebilir.

sudo journalctl -k --since '1 hour ago' | grep -Ei 'out of memory|oom|killed process'
sudo journalctl -u ornek-uygulama.service --since '1 hour ago'

Buradaki ornek-uygulama.service temsilî bir servis adıdır; kendi sisteminizdeki gerçek adla değiştirin. Günlükte görülen sonlandırılmış süreç her zaman sorunun ilk nedeni değildir. Örneğin büyük bir içe aktarma işi belleği doldururken çekirdek, aynı kaynak grubundaki başka bir süreci seçmiş olabilir. Bu nedenle olay saatindeki uygulama günlüklerini, zamanlanmış işleri ve trafik değişimini birlikte inceleyin.

Mevcut RAM ve süreç kullanımını karşılaştırın

free -h
ps -eo pid,ppid,comm,rss,%mem --sort=-rss | head -n 16
cat /proc/pressure/memory

free -h çıktısında özellikle kullanılabilir bellek değerini inceleyin; önbellekte kullanılan RAM'i doğrudan kayıp kapasite olarak yorumlamayın. ps çıktısındaki rss, sürecin fiziksel bellekte yerleşik kısmını gösterir; paylaşılan belleğin süreçler arasında nasıl sayıldığına dikkat etmeden satırları toplamak kesin toplam vermez. /proc/pressure/memory dosyası ise PSI (baskı nedeniyle bekleme bilgisi) ölçümlerini sunar. Buradaki yükselen bekleme oranları, yalnızca kapasiteyi değil, bellek baskısının iş yükünü ne kadar yavaşlattığını değerlendirmeye yardımcı olur.

Servisin kendi sınırını kontrol edin

systemctl show ornek-uygulama.service -p MemoryHigh -p MemoryMax -p MemoryCurrent -p ControlGroup
systemctl status ornek-uygulama.service

cgroup v2 kullanılan bir sistemde servis için gösterilen kontrol grubu yolundan ilgili memory.events dosyasına ulaşabilirsiniz. Örneğin yol /system.slice/ornek-uygulama.service ise aşağıdaki denetimi yapın:

cat /sys/fs/cgroup/system.slice/ornek-uygulama.service/memory.events

memory.events içindeki high, max, oom ve oom_kill sayaçları farklı olayları ifade eder; max değerinin artması tek başına bir sürecin öldürüldüğünü kanıtlamaz. oom_kill değişimini olay öncesi ve sonrası ölçümlerle karşılaştırmak daha yararlıdır. Bu dosyadaki sayaçlar alt grupları kapsayabilir; yalnızca ilgili grubun yerel olaylarını görmek için, mevcutsa memory.events.local dosyasını inceleyin.

Servis Bazında Bellek Sınırları

Bir uygulamanın denetimsiz biçimde bütün belleği tüketmesini önlemek için servis bazında kaynak sınırları kullanılabilir. Ancak sınırların gelişigüzel düşürülmesi kesinti sayısını artırır. Ölçülen normal kullanım, yük altındaki tepe değer ve aynı makinedeki diğer hizmetlerin gereksinimleri birlikte değerlendirilmelidir.

cgroup v2 düzeyinde memory.high eşiği aşılınca süreçler yavaşlatılıp bellek geri kazanımı baskısına maruz kalabilir; tek başına bu eşiğin aşılması OOM Killer'ı çalıştırmaz. memory.max ise sert sınırdır ve kullanım sınırına ulaşıp bellek geri kazanılamadığında grup içinde OOM koşulu oluşabilir. Bu nedenle yumuşak baskı eşiği ile son sınırın farklı amaçları vardır.

Örnek olarak bir servisin ölçülen tepe kullanımı 900 MB ise doğrudan 900 MB sert sınır koymak, olağan dalgalanmalarda bile kesintiye neden olabilir. 1,2 GB baskı eşiği ve 1,5 GB sert sınır, ancak sunucunun geri kalan hizmetlerine yeterli kaynak bırakıyorsa değerlendirmeye alınabilecek temsilî bir başlangıçtır. Bu sayılar evrensel öneri değildir; gerçek ölçümlere ve yük testine göre uyarlanmalıdır.

Değişiklik için mevcut birimi doğrudan düzenlemek yerine bir servis ek yapılandırması kullanılabilir. Aşağıdaki içerik, sudo systemctl edit ornek-uygulama.service komutuyla açılan düzenleyicide kullanılabilecek bir örnektir:

[Service]
MemoryHigh=1200M
MemoryMax=1500M

Kaydettikten sonra etkin ayarları systemctl show ile doğrulayın. Değişikliğin çalışan servise nasıl uygulanacağını sisteminizin servis yönetimi davranışına göre kontrol edin; yeniden başlatma gerekiyorsa bunu bakım penceresinde yapın. Veritabanı gibi kritik hizmetlerde sınır koymadan önce yoğun sorguların, bakım işlemlerinin ve eşzamanlı bağlantıların tepe kullanımını mutlaka ölçün.

Bellek Tükenmesini Önleme Stratejileri

Kapasite bütçesi oluşturun

Sunucunun kurulu RAM miktarından işletim sisteminin ve zorunlu hizmetlerin payını ayırın. Kalan alanı uygulama, veritabanı, kuyruk işçileri ve kısa süreli bakım görevleri arasında planlayın. Sadece ortalama kullanım değil, aynı anda gerçekleşebilecek tepe talepleri önemlidir. Örneğin gece yedeği alınırken gündüz yoğunluğuna benzer bir içe aktarma da çalışabiliyorsa iki işin birlikte gerektirdiği belleği hesaba katın.

İşçi sayısını ve görev eşzamanlılığını sınırlayın

Bir web uygulamasında süreç başına ortalama 180 MB tüketen sekiz işçi, yalnızca işçiler açısından yaklaşık 1,44 GB kullanım anlamına gelir. Veritabanı ve işletim sistemi bu hesabın dışındadır. Eşzamanlı işçi sayısını düşürmek geçici bir önlem olabilir; fakat isteklerin kuyrukta bekleme süresini de artırabilir. Amaç mümkün olan en az süreç değil, trafik ve kapasite için dengeli bir sayıdır.

Artan kullanımı ve bellek baskısını izleyin

Belirli bir görev tamamlandıktan sonra kullanım normale dönmüyorsa uygulamanın bellek yönetimini inceleyin. Tek bir anlık görüntü yerine düzenli ölçüm alın: kullanılabilir RAM, swap etkinliği, hizmetlerin bellek tüketimi ve PSI verileri birlikte anlamlıdır. Bellek baskısı ölçümleri, OOM oluşmadan önce yavaşlama eğilimini yakalamaya yardımcı olabilir.

Yanlış çözümlerden kaçının

• Körlemesine önbellek temizleme: Dosya önbelleğinin kullanımı tek başına arıza değildir; sürekli temizlemek altta yatan talebi gidermez.
• Herkese OOM koruması verme: Süreç seçimini değiştirmek bellek üretmez ve arıza anındaki davranışı öngörmeyi zorlaştırabilir.
• Yalnızca swap büyütme: Geçici alan sağlasa da sürekli yüksek bellek talebini veya sızıntıyı çözmez.
• Yalnızca RAM artırma: Kapasite artışı gerekli olabilir; ancak kontrolsüz işçi sayısı veya sızıntı sürüyorsa sorun daha geç tekrar edebilir.

Uygulama mimarisi tek sunucunun kapasitesini düzenli olarak aşıyorsa sanal sunucu kaynaklarını büyütmek, iş yüklerini ayrı sunuculara ayırmak veya uygun bir bulut sunucu mimarisi değerlendirmek daha kalıcı olabilir. Ölçeklendirme kararını vermeden önce sorunun gerçekten kapasiteden mi, yapılandırmadan mı kaynaklandığını ölçümlerle doğrulayın.

Örnek Uygulama Senaryosu

Bir ekip, aynı VDS üzerinde web uygulaması, veritabanı ve rapor işçisi çalıştırıyor olsun. Rapor üretildiği akşam uygulama kısa süreliğine erişilemez hâle geliyor. İlk bakışta toplam RAM'in tamamı dolu görünmediği için ağ sorunu düşünülüyor. Oysa çekirdek günlüğü uygulama işçilerinden birinin sonlandırıldığını gösteriyor; servis grubundaki oom_kill sayacı da artmış durumda. Aynı saatlerde rapor işçisi ve uygulama işçilerinin eşzamanlı çalıştığı anlaşılıyor.

Bu durumda izlenecek sıralama, önce kanıtları toplamak, sonra raporun bellek tepe değerini ölçmek ve işçi eşzamanlılığını sınamaktır. Rapor görevini daha küçük parçalara ayırmak veya daha sakin bir saate taşımak, uygulama için makul bir kaynak bütçesi belirlemek ve gerektiğinde hizmetleri farklı sunuculara dağıtmak seçenekler arasındadır. Her değişiklikten sonra yük testiyle yanıt süresini ve OOM sayaçlarını yeniden kontrol etmek gerekir. Örnekteki amaç, yalnızca sonlandırılan süreci yeniden başlatmak değil, aynı anda oluşan bellek talebini yönetmektir.

Sıkça Sorulan Sorular

Sonuç

OOM Killer olaylarında etkili müdahale, sonlandırılan süreci bulmakla başlar; sistem genelindeki bellek baskısını servis sınırlarından ayırmak, eşzamanlı iş yüklerini ölçmek ve kapasiteyi buna göre planlamakla tamamlanır. Günlük kayıtları, memory.events sayaçları ve bellek baskısı ölçümleri birlikte değerlendirildiğinde tekrarlayan kesintilerin nedeni daha açık hâle gelir.

İş yükünüzün artık mevcut altyapıya sığmadığını ölçümlerle doğruladıysanız Corelux Sanal Sunucu, Bulut Sunucu ve Kiralık Sunucu seçeneklerini kapasite ihtiyacınıza göre karşılaştırabilirsiniz. Önce tanılama, ardından doğru boyutlandırma; yalnızca daha fazla RAM eklemekten daha sağlıklı bir yol haritası sunar.