OOM Killer Nedir? Linux RAM Bittiğinde Ne Olur?

OOM Killer nedir sorusu, Linux sunucularda RAM tamamen tükendiğinde ortaya çıkan en önemli sistem davranışlarından birini anlamak için oldukça önemlidir.

Bir Linux VDS üzerinde CPU kullanımı normal olabilir, disk yeterli boş alana sahip olabilir ve network tarafında herhangi bir problem bulunmayabilir. Buna rağmen sunucudaki RAM ve kullanılabilir bellek kaynakları kritik seviyeye ulaştığında Linux, sistemi ayakta tutabilmek için bazı process’leri sonlandırabilir.

Bu mekanizmaya OOM Killer, yani Out Of Memory Killer adı verilir.

Örneğin bir sunucuda MySQL, PHP-FPM, Nginx, Node.js veya başka bir uygulama beklenmedik şekilde kapanıyorsa ve loglarda Out of memory veya Killed process mesajları görülüyorsa OOM Killer devreye girmiş olabilir.

💡 İpucu: Bir uygulamanın hiçbir açık hata vermeden kapanması, her zaman uygulamanın kendisinde problem olduğu anlamına gelmez. Linux kernel’in OOM mekanizması tarafından sonlandırılmış bir process de aynı şekilde dışarıdan “uygulama çöktü” gibi görünebilir.

Bu rehberde OOM Killer nedir, Linux RAM bittiğinde ne olur, hangi process’in neden seçildiği nasıl belirlenir, OOM logları nasıl incelenir, oom_score ve oom_score_adj nedir, Swap’ın OOM Killer ile ilişkisi nasıldır ve systemd-oomdnasıl çalışır sorularını detaylı şekilde inceleyeceğiz.

🧠 OOM Killer Nedir ve Neden Kullanılır?

OOM Killer nedir sorusunun temel cevabı, Linux kernel’in ciddi bir bellek yetersizliği durumunda uygun gördüğü process’lerden birini sonlandırarak sistemin bellek baskısından çıkmasına yardımcı olan mekanizmadır.

Linux’ta çalışan her uygulama RAM kullanır.

Örneğin:

Nginx
PHP-FPM
MySQL
Redis
Node.js
Docker
Minecraft
Metin2

gibi servislerin tamamı sistem belleğinden pay alır.

Zaman içerisinde RAM kullanımı arttığında sistem önce kullanılabilir bellek alanlarını değerlendirmeye, gerektiğinde Swap kullanmaya ve bellek baskısını yönetmeye çalışır.

Ancak sistemin kullanabileceği bellek kaynakları tükendiğinde kernel’in bir process’i sonlandırması gerekebilir.

Linux kernel dokümantasyonuna göre OOM Killer, bellek yetersizliği durumunda process’leri belirli heuristiklere göre değerlendirerek bir hedef seçer.

Dolayısıyla OOM Killer’ın amacı rastgele uygulama kapatmak değil, sistemin tamamen kilitlenmesini önlemek için bellek kaynaklarını yeniden kullanılabilir hale getirmektir.

💾 Linux RAM Bittiğinde Ne Olur?

Bir Linux sunucuda RAM kullanımının yükselmesi tek başına OOM anlamına gelmez.

Kabaca süreç şu şekilde düşünülebilir:

Uygulamalar RAM kullanır
        ↓
Kullanılabilir RAM azalır
        ↓
Kernel bellek yönetimi devreye girer
        ↓
Gerekirse Swap kullanılır
        ↓
Memory pressure artar
        ↓
Kullanılabilir bellek yetersiz kalır
        ↓
OOM mekanizması devreye girebilir
        ↓
Bir process sonlandırılabilir

Burada önemli olan nokta, Linux’un RAM kullanımını yalnızca “boş RAM” üzerinden değerlendirmemesidir.

Dosya cache’leri ve diğer kernel bellek kullanımları da sistemin genel bellek durumunun parçasıdır.

Bu nedenle:

free -h

çıktısındaki used değerini görüp doğrudan “RAM tamamen doldu” demek doğru olmayabilir.

🔄 Swap ile OOM Killer Arasındaki İlişki Nedir?

Swap, fiziksel RAM’e alternatif olarak disk üzerinde kullanılan bir bellek alanıdır.

RAM baskısı oluştuğunda Linux bazı bellek sayfalarını Swap alanına taşıyabilir.

Örneğin:

free -h

çıktısında:

               total   used   free
Mem:            16Gi    15Gi   ...
Swap:            4Gi     2Gi   ...

gibi bir tablo görülebilir.

Ancak Swap’ın bulunması OOM Killer’ın hiçbir zaman çalışmayacağı anlamına gelmez.

Eğer RAM ve kullanılabilir Swap kaynakları da sistemin ihtiyacını karşılayamazsa OOM durumu yine ortaya çıkabilir.

⚠️ Dikkat: Swap’ı artırmak her OOM problemini çözmez. Eğer uygulamanın gerçek bellek ihtiyacı fiziksel RAM kapasitesinin çok üzerindeyse daha fazla Swap kullanılması problemi yalnızca geciktirebilir ve disk I/O yükünü artırabilir.

Linux bellek kullanımını daha ayrıntılı incelemek için vmstat ile CPU, RAM ve Disk performansını analiz etme rehberimizdeki yöntemlerden yararlanabilirsiniz.

📊 OOM Killer Hangi Process’i Öldürür?

Linux’un OOM Killer mekanizması herhangi bir process’i tamamen rastgele seçmez.

Kernel, aday process’leri değerlendirirken OOM score adı verilen bir skor kullanır.

Bir process’in:

cat /proc/PID/oom_score

dosyası okunarak mevcut OOM skoruna bakılabilir.

Örneğin:

cat /proc/1234/oom_score

çıktısı:

650

olabilir.

Genel olarak skor yükseldikçe process’in OOM Killer tarafından seçilme olasılığı artar. Linux man-pages dokümantasyonu da oom_score değerinin kernel’in process seçiminde kullandığı skoru gösterdiğini ve daha yüksek skorun daha yüksek seçilme olasılığı anlamına geldiğini belirtir.

🔍 Teknik Not: oom_score, “bu process kesinlikle öldürülecek” anlamına gelmez. Kernel’in OOM seçim mekanizmasında kullanılan faktörlerden biridir.

🎯 oom_score Nedir?

oom_score, Linux kernel’in bir process’i OOM Killer açısından değerlendirmek için kullandığı skoru gösterir.

Kontrol etmek için:

cat /proc/PID/oom_score

kullanılabilir.

Örneğin:

cat /proc/2450/oom_score

çıktısı:

780

olabilir.

Başka bir process’te:

120

görülebilir.

Bu iki process aynı anda OOM adayı olduğunda yüksek skorlu process’in seçilme ihtimali daha yüksek olabilir.

Ancak kernel’in değerlendirmesi yalnızca basit bir “en çok RAM kullanan process’i öldür” kuralından ibaret değildir.

⚙️ oom_score_adj Nedir?

oom_score_adj, bir process’in OOM Killer tarafından seçilme eğilimini değiştirmek için kullanılan ayardır.

Kontrol etmek için:

cat /proc/PID/oom_score_adj

kullanabilirsiniz.

Örneğin:

cat /proc/1234/oom_score_adj

çıktısı:

0

olabilir.

Linux kernel dokümantasyonuna göre oom_score_adj değeri -1000 ile +1000 arasında olabilir. Pozitif değerler process’in OOM sırasında seçilme eğilimini artırırken negatif değerler azaltır; -1000 değeri process’i OOM seçiminden koruyacak şekilde kullanılır.

Örneğin:

echo 500 > /proc/PID/oom_score_adj

ilgili process’i OOM seçiminde daha tercih edilebilir hale getirebilir.

Ancak bu değerleri gelişigüzel değiştirmek doğru değildir.

⚠️ Dikkat: Kritik bir servisi OOM Killer’dan korumaya çalışırken diğer process’lerin daha kolay hedef haline gelmesine neden olabilirsiniz. Bu nedenle oom_score_adj değişiklikleri gerçek servis mimarisi bilinerek yapılmalıdır.

🔎 OOM Killer Çalıştığını Nasıl Anlarız?

OOM durumunu tespit etmenin en önemli yollarından biri sistem loglarını incelemektir.

Örneğin:

dmesg | grep -i oom

ve:

dmesg | grep -i "killed process"

komutları kullanılabilir.

Systemd kullanan modern Linux dağıtımlarında ise:

journalctl -k | grep -i oom

ve:

journalctl -k | grep -i "out of memory"

komutları faydalı olabilir.

Örneğin loglarda:

Out of memory: Killed process 1234

benzeri bir kayıt görülmesi OOM olayına güçlü bir işaret olabilir.

🚨 Killed Process Logu Ne Anlama Gelir?

Aşağıdaki gibi bir kernel mesajı düşünelim:

Out of memory: Killed process 1234 (mysqld)

Burada:

1234

process ID’sini,

mysqld

ise sonlandırılan process’in adını ifade eder.

Bu durumda MySQL’in kendiliğinden kapandığını düşünmek yerine kernel loglarını incelemek gerekir.

Ardından:

free -h

ile RAM ve Swap durumu,

ps aux --sort=-%mem | head

ile yüksek bellek kullanan process’ler kontrol edilebilir.

🧪 OOM Problemi Nasıl Adım Adım Analiz Edilir?

Bir VDS sunucuda uygulamanın aniden kapandığını düşünelim.

1. RAM durumunu kontrol edin

free -h

2. Swap kullanımını kontrol edin

swapon --show

3. En fazla RAM kullanan process’leri bulun

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

4. Kernel loglarını inceleyin

journalctl -k | grep -i oom

5. Sonlandırılan process’i bulun

journalctl -k | grep -i "killed process"

6. Process’in OOM skorunu inceleyin

cat /proc/PID/oom_score

7. OOM score adjustment değerini kontrol edin

cat /proc/PID/oom_score_adj

Bu kontroller sayesinde sorunun gerçekten OOM kaynaklı olup olmadığı daha net anlaşılabilir.

🖥️ VDS Sunucularda OOM Killer Neden Oluşur?

Bir VDS’de OOM oluşmasının birçok nedeni olabilir.

Örneğin:

• Yetersiz RAM
• Çok fazla çalışan servis
• Bellek tüketen uygulama
• Memory leak
• Yanlış PHP-FPM yapılandırması
• Çok yüksek MySQL bellek kullanımı
• Node.js uygulamasında aşırı heap kullanımı
• Docker container’larının toplam bellek tüketimi
• Çok sayıda oyun sunucusu
• Aşırı cache kullanımı
• Yetersiz kaynak planlaması

Örneğin 4 GB RAM’e sahip bir VDS üzerinde aynı anda:

MySQL
Nginx
PHP-FPM
Redis
Docker

çalıştırmak, uygulamaların gerçek bellek ihtiyaçlarına bağlı olarak ciddi memory pressure oluşturabilir.

Bu nedenle VDS satın alırken yalnızca CPU çekirdek sayısına değil RAM kapasitesine de dikkat etmek gerekir.

🧩 Metin2 Sunucusunda OOM Killer Çalışabilir mi?

Evet.

Metin2 server altyapısında birden fazla process, database servisi ve yardımcı servis çalışabilir.

Özellikle:

• Game Core
• Auth
• Database
• Channel’lar
• Web paneli
• Log servisleri
• Yardımcı daemon’lar

aynı sunucu üzerinde çalışıyorsa toplam RAM kullanımı önem kazanır.

Bu nedenle Metin2 altyapısında RAM planlaması yapılırken yalnızca Game Core’un tüketimi değil, sunucudaki bütün servislerin toplam kaynak kullanımı değerlendirilmelidir.

Metin2 tarafında RAM planlaması için Metin2 RAM gereksinimi: Server için kaç GB RAM gerekir? rehberimizde farklı sunucu senaryolarına göre RAM ihtiyacını inceleyebilirsiniz.

CPU tarafındaki kaynak planlaması için de Metin2 CPU gereksinimi: Server için kaç çekirdek gerekir? içeriğimizle birlikte değerlendirme yapmak daha doğru olacaktır.

🐳 Docker Container OOM Neden Olur?

Docker kullanılan sunucularda OOM konusu biraz daha farklı değerlendirilebilir.

Bir container’ın bellek tüketimi:

Container
    ↓
Memory limit
    ↓
cgroup
    ↓
Kernel memory management

üzerinden kontrol edilebilir.

Örneğin container belirli bir memory limit ile çalışıyorsa container’ın kendi sınırına ulaşması ile host sisteminin tamamen OOM olması aynı durum değildir.

Bu nedenle Docker kullanılan VDS’lerde:

docker stats

ile container’ların RAM kullanımını takip etmek faydalıdır.

Ardından host sisteminde:

free -h

ve:

journalctl -k | grep -i oom

kontrolleri yapılabilir.

🔍 Teknik Not: Container içindeki bir memory limit problemi ile host kernel’in genel OOM durumu birbirinden ayrılmalıdır. Sorunun hangi seviyede oluştuğunu belirlemek doğru teşhis için önemlidir.

🟢 Node.js OOM Problemi

Node.js uygulamalarında iki farklı durum birbirine karıştırılabilir.

Birincisi Node.js’in kendi heap sınırına ulaşmasıdır.

Örneğin:

JavaScript heap out of memory

gibi bir hata görülebilir.

İkincisi ise Linux kernel’in sistem genelinde bellek yetersizliği nedeniyle Node.js process’ini OOM Killer ile sonlandırmasıdır.

Bu iki durumda görülen hata mesajları ve teşhis yöntemleri farklı olabilir.

Dolayısıyla:

Node.js heap problemi

ile:

Linux kernel OOM

aynı şey değildir.

🗄️ MySQL OOM Problemi

MySQL veya MariaDB’nin yüksek RAM kullanması da OOM problemlerine yol açabilir.

Özellikle:

• Buffer pool
• Connection sayısı
• Query memory
• Temporary table kullanımı
• Cache
• Birden fazla database servisi

toplam RAM tüketimini artırabilir.

Bu nedenle MySQL’in RAM kullanımını değerlendirirken yalnızca tek bir ayara bakmak yerine toplam sistem kaynakları incelenmelidir.

Örneğin:

free -h

ile sistem belleğini,

ps aux --sort=-%mem | head

ile process bazlı kullanımı inceleyebilirsiniz.

📈 RAM Kullanımı %90 Olduğunda OOM Olur mu?

Hayır.

RAM kullanımının %90 olması otomatik olarak OOM Killer’ın çalışacağı anlamına gelmez.

Benzer şekilde:

RAM %80

durumunda kesinlikle sorun yoktur demek de doğru değildir.

OOM kararı sistemin gerçek bellek baskısı ve kullanılabilir kaynaklarıyla ilişkilidir.

Bu nedenle yalnızca yüzde değerine bakmak yerine:

free -h

çıktısı,

vmstat

verileri,

Swap kullanımı ve kernel logları birlikte değerlendirilmelidir.

🔄 Swap Artırmak OOM Killer Problemini Çözer mi?

Bazen bellek baskısını azaltmaya yardımcı olabilir ancak garantili bir çözüm değildir.

Örneğin 8 GB RAM’e sahip bir VDS’de 4 GB Swap bulunması, uygulamaların 12 GB RAM varmış gibi performans göstereceği anlamına gelmez.

Swap disk üzerinde bulunduğu için yoğun Swap kullanımı fiziksel RAM’e kıyasla çok daha yüksek gecikmelere neden olabilir.

Bu nedenle:

RAM
+
Uygulama ihtiyacı
+
Swap
+
Disk performansı

birlikte değerlendirilmelidir.

⚠️ Dikkat: Swap’ı artırmak, yetersiz RAM kapasitesinin yerine geçmez. Sürekli yoğun Swap kullanımı varsa asıl problemin bellek planlaması olması mümkündür.

⚙️ systemd-oomd Nedir?

Modern Linux sistemlerinde OOM konusu yalnızca kernel OOM Killer’dan ibaret değildir.

Bazı systemd tabanlı sistemlerde systemd-oomd adlı kullanıcı alanı servisi de kullanılabilir.

systemd-oomd, cgroups v2 ve Pressure Stall Information (PSI) verilerini kullanarak bellek baskısını izleyebilir ve kernel OOM oluşmadan önce yapılandırılmış koşullara göre müdahale edebilir.

Kontrol etmek için:

systemctl status systemd-oomd

kullanılabilir.

Çalışıyorsa:

journalctl -u systemd-oomd

ile ilgili loglar incelenebilir.

Bu nedenle modern bir Linux sunucuda bellek kaynaklı bir process sonlandırıldığında:

Kernel OOM Killer mı?

veya

systemd-oomd mı?

sorusunu ayırmak önemlidir.

🧠 OOM Killer ile systemd-oomd Arasındaki Fark

İki mekanizma benzer bir probleme farklı seviyelerde yaklaşır.

systemd-oomd, yapılandırılan cgroup’ları PSI ve Swap baskısı üzerinden izleyerek uygun gördüğü durumda cgroup içindeki process’leri sonlandırabilir.

🔐 Kritik Process’leri OOM’dan Korumak Mümkün mü?

Linux’ta oom_score_adj ile bir process’in OOM seçimindeki önceliği değiştirilebilir.

Örneğin:

cat /proc/PID/oom_score_adj

ile mevcut değer görülebilir.

Daha düşük bir değer process’in seçilme ihtimalini azaltabilir.

Ancak:

echo -1000 > /proc/PID/oom_score_adj

gibi bir yapılandırmayı gelişigüzel uygulamak doğru değildir.

Çünkü sistemdeki diğer process’ler yine bellek tüketmeye devam eder.

Bir process’i korumak, toplam RAM ihtiyacını ortadan kaldırmaz.

⚠️ Dikkat: OOM’dan kritik bir servisi korumaya çalışırken sistemde başka bir process’in öldürülmesine neden olabilirsiniz. Bu nedenle oom_score_adj değişiklikleri servis bağımlılıkları bilinerek yapılmalıdır.

📊 OOM Killer ve ulimit Arasındaki İlişki

Bir önceki yazımızda incelediğimiz ulimit, process’lerin belirli kaynakları kullanabileceği limitleri yönetmek için kullanılır.

OOM Killer ise sistemin ciddi bellek yetersizliği durumunda devreye giren kernel mekanizmasıdır.

Yani:

ulimit ≠ OOM Killer

Örneğin:

ulimit
↓
Process resource limitleri

iken:

OOM Killer
↓
Sistem/cgroup bellek baskısı
↓
Process seçimi

şeklinde düşünebiliriz.

Linux’ta process kaynak limitlerini detaylı incelemek için ulimit nedir? Linux sunucuda dosya ve process limitleri rehberimize göz atabilirsiniz.

Bu iki mekanizmanın birbirine karıştırılmaması özellikle sistem yöneticileri için önemlidir.

🔍 OOM Problemini Önlemek İçin Neler Yapılabilir?

OOM Killer’ı tamamen “kapatmaya” çalışmak yerine bellek probleminin kaynağını çözmek daha doğru bir yaklaşımdır.

1. RAM kapasitesini doğru planlayın

Sunucuda çalışan bütün servislerin toplam RAM ihtiyacını hesaplayın.

2. Gereksiz servisleri kapatın

Kullanılmayan servisler boş yere RAM tüketebilir.

3. Uygulama bellek kullanımını izleyin

ps aux --sort=-%mem | head

gibi komutlarla en fazla RAM tüketen process’leri bulun.

4. Swap durumunu kontrol edin

swapon --show

5. Kernel loglarını takip edin

journalctl -k | grep -i oom

6. Container kullanıyorsanız memory limitlerini inceleyin

docker stats

7. Memory leak ihtimalini araştırın

Bir process’in RAM kullanımı sürekli artıyorsa uygulama kaynaklı bir bellek problemi olabilir.

8. VDS kaynaklarını gerektiğinde yükseltin

Uygulamanın gerçek RAM ihtiyacı mevcut VDS kapasitesini sürekli aşıyorsa daha fazla RAM’e sahip bir altyapıya geçmek gerekebilir.

🛠️ VDS’de OOM Teşhis Kontrol Listesi

Bir uygulamanın OOM nedeniyle kapandığını düşünüyorsanız şu sırayla ilerleyebilirsiniz:

free -h

swapon --show

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

journalctl -k | grep -i oom

journalctl -k | grep -i "killed process"

systemctl status systemd-oomd

journalctl -u systemd-oomd

Sonrasında problem yaşayan process için:

cat /proc/PID/oom_score

ve:

cat /proc/PID/oom_score_adj

kontrol edilebilir.

Bu yaklaşım, “RAM dolmuş, RAM ekle” şeklindeki yüzeysel teşhis yerine sorunun hangi seviyede oluştuğunu anlamaya yardımcı olur.

VDS üzerinde genel kaynak darboğazlarını analiz etmek için VDS sunucuda darboğaz nasıl tespit edilir? CPU, RAM ve Disk analizi rehberimizle birlikte değerlendirme yapabilirsiniz.

🧪 Örnek OOM Senaryosu

8 GB RAM bulunan bir VDS üzerinde şu servislerin çalıştığını düşünelim:

Nginx       → 300 MB
PHP-FPM     → 1.5 GB
MySQL       → 3 GB
Redis       → 500 MB
Docker      → 1.5 GB
Diğerleri   → 1 GB

Toplam kullanım zaman içerisinde fiziksel RAM kapasitesine yaklaşabilir.

Bir uygulamanın bellek tüketimi daha da arttığında sistemin kullanılabilir belleği azalır.

Swap yeterli değilse veya bellek baskısı daha da yükselirse kernel OOM mekanizması devreye girebilir.

Bu durumda örneğin MySQL veya başka bir process sonlandırılmış olabilir.

Sorunun kaynağını anlamak için yalnızca sonlandırılan process’e bakmak yeterli değildir.

Asıl soru:

Bu process neden bu kadar RAM kullanıyordu?

olmalıdır.

Çünkü OOM Killer çoğu zaman problemin kendisi değil, bellek yetersizliğinin sonucudur.

📌 OOM Killer Çalıştıktan Sonra Ne Yapılmalı?

Bir process OOM Killer tarafından sonlandırıldıysa yalnızca servisi yeniden başlatmak yeterli olmayabilir.

Öncelikle:

🔎 1. Kernel loglarını inceleyin

journalctl -k

📊 2. RAM kullanım geçmişini araştırın

Mümkünse monitoring verilerine bakın.

🧠 3. En fazla RAM tüketen process’leri bulun

ps aux --sort=-%mem | head

🔄 4. Swap kullanımını kontrol edin

swapon --show

🐳 5. Docker varsa container’ları inceleyin

docker stats

⚙️ 6. systemd-oomd kullanılıyorsa loglarını kontrol edin

journalctl -u systemd-oomd

📈 7. RAM kapasitesini yeniden değerlendirin

Sorun sürekli tekrarlanıyorsa mevcut VDS kaynakları uygulamanın gerçek ihtiyacını karşılamıyor olabilir.

❓ Sık Sorulan Sorular

OOM Killer nedir?

OOM Killer, Linux kernel’in ciddi bellek yetersizliği durumunda uygun bir process’i seçerek sonlandırmasına yardımcı olan mekanizmadır.

Linux RAM bitince ne olur?

Linux önce mevcut bellek kaynaklarını yönetmeye çalışır ve uygun durumda Swap kullanabilir. Bellek kaynakları kritik şekilde tükendiğinde OOM mekanizması devreye girebilir ve bir process sonlandırılabilir.

OOM Killer neden process öldürür?

Amaç bellek yetersizliği durumunda sistemin tamamen kilitlenmesini önlemek ve kullanılabilir belleği yeniden sağlamaktır.

Hangi process’in öldürüleceğine nasıl karar verilir?

Linux kernel, process’leri OOM skoru ve çeşitli kernel heuristikleri üzerinden değerlendirir. Daha yüksek oom_scoredeğeri genel olarak process’in seçilme ihtimalini artırır.

oom_score nedir?

oom_score, kernel’in bir process’i OOM Killer açısından değerlendirmek için kullandığı skoru gösterir.

oom_score_adj nedir?

oom_score_adj, bir process’in OOM Killer tarafından seçilme eğilimini değiştirmek için kullanılan ayardır. Değer aralığı -1000 ile +1000 arasındadır.

Swap artırmak OOM problemini çözer mi?

Her zaman çözmez. Swap bellek baskısını azaltabilir ancak fiziksel RAM’in yerini tamamen tutmaz. Sürekli yoğun Swap kullanımı performans sorunlarına da yol açabilir.

systemd-oomd nedir?

systemd-oomd, systemd tarafından sağlanan userspace OOM yönetim servisidir. cgroups v2 ve PSI verilerini kullanarak yapılandırılmış koşullarda kernel OOM oluşmadan önce müdahale edebilir.

Docker container neden OOM ile kapanır?

Container’ın kendi memory limitine ulaşması veya host sistemin genel bellek baskısına girmesi farklı OOM senaryoları oluşturabilir. Bu nedenle container ve host seviyeleri ayrı ayrı incelenmelidir.

OOM Killer nasıl kontrol edilir?

İlk olarak:

journalctl -k | grep -i oom

ve:

journalctl -k | grep -i "killed process"

komutlarıyla kernel logları incelenebilir.

🏁 Sonuç

OOM Killer nedir sorusunun temel cevabı, Linux kernel’in ciddi bellek yetersizliği durumunda sistemin çalışmaya devam edebilmesi için uygun gördüğü process’leri sonlandırabilen bellek yönetimi mekanizmasıdır.

Özellikle VDS sunucularda:

• RAM kapasitesi
• Swap
• Process bellek kullanımı
• oom_score
• oom_score_adj
• Kernel logları
• cgroups
• systemd-oomd

birlikte değerlendirilmelidir.

En önemli nokta ise OOM Killer’ın genellikle asıl problemin kendisi olmadığıdır.

Bir process’in OOM Killer tarafından öldürülmesi çoğu zaman sunucunun mevcut bellek kaynaklarının uygulamaların ihtiyacını karşılamakta zorlandığını gösteren bir belirtidir.

Bu nedenle yalnızca process’i yeniden başlatmak yerine hangi uygulamanın neden bu kadar RAM kullandığınıaraştırmak gerekir.

AydınCloud üzerinde Linux ve VDS performans analizlerini birlikte değerlendirmek için vmstat, pidstat, ulimit ve VDS darboğaz analizleri gibi teknik rehberleri birbirine bağlamak, sorunların kaynağını daha sistematik şekilde incelemeyi sağlar.

💡 Son İpucu: Bir VDS’de uygulamanız durduk yere kapanıyorsa ilk bakmanız gereken yerlerden biri kernel loglarıdır. Out of memory veya Killed process kayıtları görüyorsanız OOM Killer ihtimalini mutlaka değerlendirin.