Sistemin Sessiz Ölümü: OOM Killer ve Benim VPS Maceram

Giriş: OOM Killer’ın Gölgesinde Bir VPS Deneyimi

Bir süredir kendi sanal özel sunucumda (VPS) çalıştırdığım uygulamaların bellek yönetimi konusunda bazı ilginç ve zaman zaman sinir bozucu deneyimler yaşadım. Özellikle yoğun dönemlerde veya beklenmedik trafik artışlarında, sistemin bellek (RAM) tüketimi kritik seviyelere ulaştığında devreye giren OOM Killer (Out-of-Memory Killer) ile tanıştım. Bu, sistemin “sessizce ölümü” olarak adlandırabileceğimiz bir durum; çünkü uygulamalarınız aniden kapanabilir, veri kaybı yaşanabilir veya sistemin tamamı yanıt vermez hale gelebilir. Bu yazıda, OOM Killer’ın ne olduğunu, neden ortaya çıktığını, benim VPS’imde karşılaştığım somut vakaları ve bu sorunla başa çıkmak için uyguladığım stratejileri detaylı bir şekilde ele alacağım.

Bu makalenin amacı, sadece bir sorunun nasıl çözüldüğünü anlatmak değil, aynı zamanda işletim sistemlerinin bellek yönetimi mekanizmalarının derinliklerine inmek ve “kurumsal danışman” tonundan uzak, doğrudan saha tecrübesiyle yoğrulmuş bir bakış açısı sunmaktır. Kendi VPS’imde yaşadığım bu macera, bana hem Linux’un karmaşık iç işleyişi hakkında paha biçilmez dersler verdi hem de sistem güvenilirliğinin ne kadar hassas bir denge üzerine kurulu olduğunu gösterdi. Özellikle 2026’nın ilk yarısında, artan iş yükleri ve daha karmaşık hale gelen servis dağıtımları, bellek yönetimi sorunlarını daha görünür hale getirdi.

OOM Killer Nedir ve Neden Ortaya Çıkar?

Linux çekirdeği (kernel), sistem kaynaklarını verimli bir şekilde yönetmek için tasarlanmıştır. Bellek (RAM), bu kaynakların en kritiklerinden biridir. Bir sistemde çalışan tüm işlemler (process’ler) bellekte yer kaplar. Eğer sistemdeki toplam bellek talebi, mevcut fiziksel RAM ve swap alanını aşarsa, çekirdek bir “bellek tükenmesi” durumuyla karşı karşıya kalır. Bu noktada, sistemin tamamen çökmesini engellemek için bir mekanizma devreye girer: OOM Killer. OOM Killer, o anda sistemde çalışan işlemler arasından birini veya birkaçını seçip sonlandırarak belleği serbest bırakmaya çalışır.

Peki, bu “bellek tükenmesi” durumu nasıl oluşur? Birden çok sebebi olabilir:

• Uygulama Hataları: Bellek sızıntısı (memory leak) olan uygulamalar zamanla giderek daha fazla bellek tüketir.
• Beklenmedik Yük Artışı: Aniden gelen trafik veya işlem yükü, mevcut kaynakları aşabilir.
• Yanlış Yapılandırma: Uygulamaların veya sistem servislerinin bellek limitlerinin yanlış ayarlanması.
• Yetersiz Kaynaklar: Sunucunun başlangıçta yeterli belleğe sahip olmaması.
• Çok Fazla Servis: Bir VPS üzerinde gereğinden fazla servisin çalıştırılması.

Benim durumumda, birkaç senaryo bir araya gelmişti. Bir üretim ERP sisteminin backend servislerinden biri, özellikle belirli raporlama sorguları çalıştırıldığında beklenenden çok daha fazla bellek tüketiyordu. Buna ek olarak, aynı VPS üzerinde çalışan bir zaman serisi veritabanı (Time Series Database - TSDB) ve birkaç küçük yardımcı servis de sürekli bir bellek yükü oluşturuyordu. Bu kombinasyon, sistemin sınırlarını zorlamaya başlamıştı.

Somut Bir Vaka: Üretim ERP’sinde Geciken Sevkiyat Raporları ve OOM Sonrası Veri Kaybı

Birkaç ay önce, büyük bir üretim firmasının ERP sisteminde çalışırken, sevkiyat raporlarının düzenli olarak geciktiğini fark ettik. Raporlar genellikle 2 saatlik bir gecikmeyle geliyordu, bu da operasyonel kararların alınmasını zorlaştırıyordu. İlk başta sorunun raporlama sorgusunun kendisinde olduğunu düşündük. Sorguyu optimize etmek için indeksler ekledik, sorgu planını inceledik ama beklenen performansı alamadık. Sorunun kök nedenini bulmak tam 3 gün sürdü.

Olayın özeti şuydu: Belirli bir tarih aralığı için sevkiyat raporu çalıştırıldığında, backend servisi muazzam miktarda veri çekiyor ve bu veriyi bellekte işliyordu. PostgreSQL veritabanı da bu sorgu için yoğun bellek kullanıyordu. Yaklaşık 1.5 saat sonra, hem uygulama servisi hem de veritabanı kendi bellek limitlerini zorlamaya başladı. VPS’in toplam belleği 32GB civarındaydı ve bu sorgu çalışırken bellek kullanımı %95’in üzerine çıkıyordu. Tam bu kritik anda, OOM Killer devreye girdi. Ancak OOM Killer, önce veritabanı işlemini, ardından da backend servisinin ana işlemini sonlandırdı.

Sonuç: Raporlama işlemi yarıda kaldı, veritabanı beklenmedik bir şekilde kapandı ve backend servisi crash oldu. Birkaç dakika sonra sistem kendini toparlamaya çalışsa da, raporlama işlemi “tamamlanmamış” olarak kaldı ve veri kaybı yaşandı. Bu durum, sadece raporlama sorununu değil, aynı zamanda operasyonel aksaklıklara ve potansiyel finansal kayıplara yol açıyordu. Bu vakadan çıkardığım en önemli derslerden biri, OOM Killer’ın sadece “kötü bir şey” olmadığı, aynı zamanda sistemin tamamen çökmesini engelleyen bir kurtarma mekanizması olduğuydu; ancak bedeli ağır olabiliyordu.

Bellek Kullanımını Analiz Etmek: top, htop ve free

OOM Killer’ı tetikleyen belleğin aşırı kullanımını anlamak ve önlemek için, sistemdeki bellek kullanımını düzenli olarak izlemek şart. Bunun için kullanabileceğimiz birkaç temel araç var:

1. top Komutu: Gerçek zamanlı olarak çalışan işlemlerin CPU ve bellek kullanımlarını gösterir. %MEM sütunu, bir işlemin toplam bellekte ne kadar yer kapladığını yüzde olarak belirtir. İşlemleri bellek kullanımına göre sıralamak için Shift + M tuşlarına basabilirsiniz.

2. htop Komutu: top komutunun daha kullanıcı dostu ve interaktif bir versiyonudur. Renkli çıktısı, işlem ağaçlarını göstermesi ve fare desteği gibi özellikleriyle daha kullanışlıdır. Bellek kullanımı, CPU kullanımı gibi bilgiler grafiksel olarak da sunulur.

3. free Komutu: Sistemin genel bellek kullanımını özetler. Kullanılan bellek, boş bellek, tamponlar (buffers) ve önbellek (cache) gibi bilgileri gösterir. free -h komutu, çıktıları insan tarafından okunabilir formatta (MB, GB gibi) gösterir.

Benim VPS maceramda bu araçlar en yakın dostlarım oldu. Sabahları ilk işim htop ile sistemin genel durumunu kontrol etmekti. Özellikle bellek kullanımı sürekli olarak %80-90 bandındaysa, bu bir alarm işaretidir. free -h komutu, o anki toplam bellek durumunu net bir şekilde gösteriyordu. Örneğin, bir keresinde free -h çıktısı şöyleydi:

              total        used        free      shared  buff/cache   available
Mem:           31Gi        29Gi       1.2Gi       100Mi       800Mi        1Gi
Swap:         2.0Gi       500Mi       1.5Gi

Bu çıktı, 31GB belleğin 29GB’ının kullanıldığını, sadece 1.2GB’ının boş olduğunu ve swap alanının da yarısının dolu olduğunu gösteriyor. Bu durum, OOM Killer’ın kısa süre içinde devreye girebileceğinin net bir göstergesiydi. Özellikle available (kullanılabilir) bellek miktarının düşük olması kritik. Bu değer, sistemin yeni işlemler başlatmak veya mevcut işlemlerin bellek taleplerini karşılamak için ne kadar “rahat” olduğunu gösterir.

OOM Killer’ı Önleme Stratejileri

OOM Killer’ın tetiklenmesini önlemek için birkaç farklı strateji izlenebilir. Bunlar, sorunun kaynağına ve sistemin yapısına göre değişiklik gösterebilir:

1. Bellek Sızıntılarını Tespit Etmek ve Düzeltmek

Bu, en ideal ve kalıcı çözümdür. Uygulamalarınızdaki bellek sızıntılarını tespit etmek için çeşitli araçlar kullanabilirsiniz:

• Valgrind: Bellek hatalarını ve sızıntılarını tespit etmek için güçlü bir araçtır. Ancak, uygulamaların çalışma hızını önemli ölçüde düşürebilir, bu yüzden genellikle geliştirme ortamında kullanılır.
• Application Performance Monitoring (APM) Araçları: Datadog, New Relic gibi APM araçları, uygulamaların bellek kullanımını izleyerek anormallikleri tespit etmenize yardımcı olur.
• Log Analizi: Uygulama loglarındaki bellek kullanımına dair ipuçlarını aramak.

Benim ERP örneğinde, sorunu tespit etmek için sorgu bazlı bellek kullanımını analiz ettim. PostgreSQL’in kendi pg_stat_activity görünümü ve sorgu logları, hangi sorguların ne kadar bellek tükettiğine dair ipuçları verdi. Sonrasında, Vue.js frontend tarafında veriyi işleyen bir fonksiyonun gereğinden fazla veri alıp bellekte tuttuğunu fark ettim. Bu fonksiyonu optimize ederek, sadece gerekli veriyi alacak ve bellekte daha az yer kaplayacak şekilde yeniden yazdım. Bu değişiklikle, raporlama sorgusunun bellek tüketimi %60 oranında azaldı.

2. Servis Bazlı Bellek Limitleri Belirlemek

Her servisin ne kadar bellek kullanabileceğini sınırlandırmak, bir servisin diğerlerini boğmasını engeller. Docker ve Kubernetes gibi konteyner orkestrasyon araçları bu konuda çok etkilidir. Ancak, bare-metal veya basit VPS kurulumlarında da systemd servis birimleri üzerinden limitler belirlemek mümkündür.

Örneğin, bir servis için systemd unit dosyasına şu satırları ekleyerek bellek limitleri belirleyebilirsiniz:

[Service]
LimitAS=2G     # Address space limit (sanallaştırılmış bellek dahil)
LimitRSS=1G    # Resident Set Size limit (fiziksel bellek)
MemoryHigh=1.5G # Yumuşak bellek sınırı, bu aşıldığında çekirdek daha dikkatli olur
MemoryMax=2G   # Sert bellek sınırı, bu aşıldığında OOM Killer devreye girme olasılığı artar

Bu yapılandırma, ilgili servisin 1.5GB’ın üzerinde bellek kullanmaya başladığında sistemin daha dikkatli olmasına yardımcı olur. Eğer 2GB’ı aşarsa, OOM Killer’ın bu servisi hedef alma olasılığı artar. Bu, kritik servislerin, özellikle de kendim geliştirdiğim ve doğrudan kontrolümde olan servislerin, üretim ERP’sine veya veritabanına zarar vermesini önlemek için kullandığım bir yöntemdi. Örneğin, kendi finansal hesaplayıcı uygulamanın backend’ini çalıştıran servise MemoryMax=512M gibi bir limit koydum, böylece kendi uygulamam sistemin genelini etkilemesin.

3. Swap Alanını Optimize Etmek veya Arttırmak

Eğer bellek sızıntısı yoksa ve mevcut uygulamalarınızın bellek ihtiyacı belliyse, ama bazen bu ihtiyacı aşabiliyorsa, swap alanını artırmak geçici bir çözüm olabilir. Ancak bu, performans düşüşüne neden olacağı için uzun vadeli bir çözüm değildir. Swap’ı optimize etmek için swappiness parametresini ayarlamak da mümkündür.

swappiness değeri 0 ile 100 arasında bir değer alır. Düşük değerler (örneğin 10), çekirdeğin belleği mümkün olduğunca swap alanına taşımaktan kaçınmasını sağlar. Yüksek değerler ise (örneğin 60, varsayılan değer), çekirdeğin belleği daha agresif bir şekilde swap alanına taşımasını teşvik eder.

swappiness değerini değiştirmek için:

# Mevcut değeri kontrol et
cat /proc/sys/vm/swappiness

# Geçici olarak değiştir (yeniden başlatmadan sonra kaybolur)
sudo sysctl vm.swappiness=10

# Kalıcı olarak değiştir (/etc/sysctl.conf dosyasını düzenleyerek)
# Dosyaya şu satırı ekle:
# vm.swappiness = 10
sudo sysctl -p

Benim VPS’imde swappiness değerini 10’a düşürmek, sistemin fiziksel belleği daha uzun süre tutmasını sağladı ve swap kullanımını azalttı. Bu, OOM Killer’ın devreye girme sıklığını azalttı ama tamamen yok etmedi.

4. Daha Fazla RAM Eklemek

En basit ve etkili çözüm, eğer mümkünse, VPS’inize daha fazla RAM eklemektir. Ancak bu, maliyetleri artırır ve her zaman mümkün olmayabilir. Eğer maliyet ve altyapı izin veriyorsa, bu genellikle en iyi ve en temiz çözümdür. Benim durumumda, VPS sağlayıcımın sunduğu en yüksek RAM kapasitesine zaten sahiptim, bu yüzden bu seçenek benim için geçerli değildi.

OOM Killer’ı Yapılandırmak: oom_score_adj ve oom_score_adj

OOM Killer’ın hangi işlemleri sonlandıracağını daha hassas bir şekilde kontrol etmek için oom_score_adj değerini ayarlayabilirsiniz. Her işlem için /proc/<PID>/oom_score_adj dosyasında bu değer bulunur. Bu değer, -1000 ile 1000 arasında olabilir.

• Negatif Değerler: İşlemin OOM Killer tarafından sonlandırılma olasılığını azaltır. Kritik servisler için kullanılır.
• Pozitif Değerler: İşlemin OOM Killer tarafından sonlandırılma olasılığını artırır. Arka planda çalışan ve öncelik tanınmayan işlemler için kullanılabilir.

Örneğin, üretim ERP’sinin backend servisi gibi kritik bir işlem için bu değeri düşürebilirsiniz:

# ERP backend işleminin PID'sini bul (örneğin 12345)
ps aux | grep my-erp-backend

# PID 12345 için oom_score_adj'ı -500 yap
echo -500 | sudo tee /proc/12345/oom_score_adj

Bu komut, o anki çalışan işlem için geçerli olur. Kalıcı hale getirmek için systemd servis biriminde veya başlangıç scriptlerinde ayarlama yapmak gerekir. Benzer şekilde, kendi geliştirdiğim yardımcı servislerden biri için oom_score_adj değerini artırarak, eğer bellek sorunu yaşanırsa ilk önce bu servisin kapanmasını sağladım.

oom_score ise, işlemin mevcut oom_score’unu gösterir. Bunu okuyarak hangi işlemlerin hedef olmaya daha yakın olduğunu görebilirsiniz:

# PID 12345 için oom_score'u oku
cat /proc/12345/oom_score

Bu araçlar, OOM Killer’ın “karar verme” mekanizmasını anlamak ve müdahale etmek için çok değerlidir.

Sonuç: Sistemin Dengesi ve Sürekli Gözetim

VPS’imde yaşadığım OOM Killer maceraları, sistemlerin ne kadar karmaşık ve hassas dengeler üzerine kurulu olduğunu bana bir kez daha gösterdi. OOM Killer, bir “hata ayıklama” aracı değil, bir “kurtarma” mekanizmasıdır ve onun devreye girmesi, genellikle daha derin bir sorunun varlığının işaretidir.

Bu süreçte öğrendiğim en önemli dersler şunlardı:

1. Sorunu Anlamak: OOM Killer’ı tetikleyen şeyin doğrudan OOM Killer değil, yetersiz bellek veya bellek sızıntısı olduğunu anlamak.
2. Gözetim (Monitoring): Sistem kaynaklarını (özellikle belleği) sürekli izlemek, sorunlar büyümeden müdahale etmeyi sağlar. htop, free ve log analizleri bu konuda kritik rol oynar.
3. Optimizasyon: Uygulamaların ve veritabanlarının bellek kullanımını optimize etmek, en kalıcı çözümdür.
4. Yapılandırma: Gerekirse servis bazlı bellek limitleri belirlemek veya oom_score_adj gibi çekirdek parametrelerini ayarlamak, sistemi koruyucu bir önlem olarak kullanılabilir.
5. Trade-off’lar: Her çözümün bir trade-off’u vardır. Swap kullanmak performansı düşürür, bellek limitleri uygulamaların tam potansiyeline ulaşmasını engelleyebilir. En iyi dengeyi bulmak önemlidir.

Teknoloji dünyasında “mükemmel” ve “hatasız” sistemler nadirdir. Önemli olan, bu sistemlerin nasıl çalıştığını anlamak, olası sorunlara hazırlıklı olmak ve karşılaştığımız problemleri pragmatik bir yaklaşımla çözmektir. OOM Killer, sistemlerin sessiz ama güçlü bir hatırlatıcısıdır: kaynakları dikkatli kullanın ve her zaman bir B planınız olsun. Bu tür deneyimler, beni daha iyi bir sistem mimarı ve operatörü yapmak için sürekli bir itici güç olmuştur.

Daha önceki VPS migration deneyimim yazımda da belirttiğim gibi, her zaman öğrenilecek yeni bir şeyler var. Bu OOM macerası da bana bellek yönetimi konusunda derinlemesine bir anlayış kazandırdı.