RAM Aşımı ve OOM Killer: Üretimde Ani Çöküşler Nasıl Önlenir?

Üretim ortamlarında çalışan uygulamalarınızın beklenmedik bir şekilde çökmesi, sistem yöneticileri ve geliştiriciler için en büyük kabuslardan biridir. Bu ani ve açıklanamayan kesintilerin arkasındaki en yaygın nedenlerden biri, genellikle RAM aşımı ve ardından devreye giren Linux Out Of Memory (OOM) Killer mekanizmasıdır. RAM aşımı, bir sistemin kullanılabilir fiziksel belleğini tükettiğinde meydana gelir ve bu durum, kritik uygulamaların sonlandırılmasına yol açabilir.

Bu blog yazısında, RAM aşımının ne olduğunu, nedenlerini ve Linux OOM Killer’ın nasıl çalıştığını detaylı bir şekilde inceleyeceğiz. Ayrıca, bu tür sorunları nasıl tespit edeceğinizi, teşhis edeceğinizi ve en önemlisi, üretim ortamlarınızda ani çöküşleri önlemek için hangi stratejileri uygulayabileceğinizi adım adım ele alacağız. Amacımız, bellek yönetimi konusundaki farkındalığınızı artırmak ve sistemlerinizi daha kararlı hale getirmenize yardımcı olmaktır.

RAM Aşımı Nedir ve Neden Gerçekleşir?

RAM aşımı, bir bilgisayar sisteminin, çalışan uygulamaların ve işletim sisteminin ihtiyaç duyduğu toplam bellek miktarının, mevcut fiziksel RAM kapasitesini aşması durumudur. Bu durum, sistemin performansının düşmesine, yavaşlamasına veya en kötü senaryoda, uygulamaların çökmesine neden olabilir. Modern işletim sistemleri, fiziksel belleğin yetersiz kaldığı durumlarda genellikle “swap alanı” adı verilen disk üzerindeki bir alanı kullanarak geçici bir çözüm sunar. Ancak swap kullanımı, disk hızlarının RAM hızlarından çok daha düşük olması nedeniyle performansta ciddi düşüşlere yol açar.

Swap alanı da dolduğunda veya etkin bir şekilde yönetilemediğinde, işletim sistemi kritik bir duruma girer. İşte bu noktada Linux çekirdeği, sistemin tamamen kilitlenmesini önlemek amacıyla OOM Killer’ı devreye sokar. OOM Killer, bellek tüketen süreçlerden bazılarını seçerek sonlandırır ve böylece sistemin genel sağlığını korumaya çalışır.

Bellek Yönetimi Temelleri

Linux gibi işletim sistemleri, belleği oldukça sofistike bir şekilde yönetir. Her süreç, kendi izole edilmiş sanal bellek alanına sahiptir. Bu sanal bellek alanları, işletim sistemi tarafından fiziksel RAM’e ve gerektiğinde disk üzerindeki swap alanına eşlenir.

Fiziksel RAM: Sistemde takılı olan gerçek bellek modülleridir. Hızlı erişim sağlar ve aktif olarak çalışan programların ve verilerin tutulduğu yerdir.
Swap Alanı: Fiziksel RAM yetersiz kaldığında, işletim sistemi az kullanılan bellek sayfalarını disk üzerindeki swap alanına taşır. Bu, sistemin daha fazla bellek kullanıyormuş gibi görünmesini sağlar ancak disk erişimi nedeniyle çok daha yavaştır. Yoğun swap kullanımı, sistemin “disk thrashing” denilen bir duruma girmesine ve performansın ciddi şekilde düşmesine neden olabilir.

Yaygın RAM Aşımı Senaryoları

RAM aşımına yol açabilecek birçok farklı senaryo bulunmaktadır. Bu senaryoları anlamak, sorunları teşhis etme ve önleme konusunda ilk adımı atmaktır.

Bellek Sızıntıları (Memory Leaks): Bir programın, tahsis ettiği belleği işi bittikten sonra serbest bırakmayı unutması durumudur. Uzun süre çalışan uygulamalarda, küçük sızıntılar bile zamanla büyük bir bellek tüketimine yol açabilir. Genellikle C/C++ gibi manuel bellek yönetimi gerektiren dillerde daha yaygın olsa da, garbage collection (çöp toplama) kullanan dillerde bile yanlış referans tutma veya nesnelerin yaşam döngüsünü yanlış yönetme nedeniyle oluşabilir.
Yanlış Yapılandırma (Misconfiguration): Uygulama sunucularının (örneğin Java için JVM heap boyutu, veritabanları için cache boyutları) veya işletim sistemi parametrelerinin yanlış ayarlanması, gereğinden fazla bellek kullanımına neden olabilir. Örneğin, bir veritabanı sunucusuna ayrılan cache boyutu, sistemdeki toplam RAM’i aşacak şekilde yapılandırılırsa, bu durum hızla RAM aşımına yol açar.
Spike Yükleri (Traffic Spikes): Beklenmedik trafik artışları veya yoğun işlem gerektiren anlık talepler, uygulamaların normalden çok daha fazla bellek kullanmasına neden olabilir. Bu durum, özellikle anlık yoğunlukları kaldırabilecek şekilde ölçeklenmemiş sistemlerde RAM aşımına yol açabilir.
Veritabanı/Cache Sorunları: Veritabanı sorgularının verimsiz olması, çok büyük sonuç kümeleri döndürmesi veya cache sistemlerinin (Redis, Memcached) yanlış yapılandırılması, anlık bellek tüketimini artırabilir. Büyük sorguların bellekte tutulması veya cache’lerin beklenenden fazla veri tutması, sistem belleğini hızla tüketebilir.
Derleyici veya Runtime Limitleri: Bazı programlama dilleri veya runtime ortamları, belirli işlemler için beklenenden daha fazla bellek ayırabilir. Örneğin, büyük bir listeyi kopyalamak veya karmaşık bir veri yapısını işlemek, düşünüldüğünden daha fazla bellek gerektirebilir.

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

Linux Out Of Memory (OOM) Killer, sistem belleği tükendiğinde devreye giren bir Linux çekirdeği özelliğidir. Amacı, sistemin tamamen kilitlenmesini veya yanıt veremez hale gelmesini önlemek için bellek tüketen bir veya daha fazla süreci sonlandırmaktır. Birçok kişi için OOM Killer, beklenmedik uygulama kapanmaları nedeniyle bir baş belası gibi görünse de, aslında sistemin hayatta kalması için son bir savunma hattıdır.

Çalışma Prensibi

OOM Killer, sistem belleği kritik seviyelere düştüğünde ve swap alanı da yetersiz kaldığında tetiklenir. Çekirdek, hangi süreçlerin sonlandırılacağına karar vermek için bir dizi faktörü değerlendiren bir algoritma kullanır. Bu algoritma, her sürece bir “oom_score” atar.

oom_score: Her sürecin, OOM Killer tarafından ne kadar “çekici” olduğunu gösteren bir değerdir. Yüksek oom_score’a sahip süreçler, sonlandırılmaya daha yatkındır. Bu skor, sürecin ne kadar bellek kullandığı, ne kadar süredir çalıştığı, hangi kullanıcının sahip olduğu gibi faktörlere göre hesaplanır. Genellikle, en fazla bellek tüketen ve en az önemli görülen süreçler daha yüksek bir oom_score alır.
oom_score_adj: Sistem yöneticileri, bu değeri kullanarak süreçlerin oom_score’unu manuel olarak ayarlayabilirler. -1000 gibi düşük bir değer atamak, bir sürecin OOM Killer tarafından sonlandırılma olasılığını büyük ölçüde azaltır. Örneğin, kritik bir veritabanı veya SSH servisi gibi süreçler için bu değeri düşük tutmak isteyebilirsiniz. +1000 gibi yüksek bir değer ise, sürecin daha kolay sonlandırılmasını sağlar.

OOM Killer, en yüksek oom_score’a sahip süreci (veya süreçleri) seçer ve onu SIGKILL sinyaliyle sonlandırır. SIGKILL, uygulamaların temiz bir şekilde kapanmasına izin vermeyen, doğrudan çekirdek tarafından gönderilen ve yakalanamayan bir sinyaldir. Bu nedenle, OOM Killer tarafından sonlandırılan uygulamalar genellikle hiçbir log kaydı bırakmadan aniden kapanır.

# Bir sürecin oom_score değerini görmek için:
cat /proc/<PID>/oom_score

# Bir sürecin oom_score_adj değerini görmek için:
cat /proc/<PID>/oom_score_adj

# Bir sürecin oom_score_adj değerini değiştirmek için (root ayrıcalığı gereklidir):
echo -1000 > /proc/<PID>/oom_score_adj

OOM Killer’ın Belirtileri

OOM Killer devreye girdiğinde, sisteminizde belirgin bazı işaretler görürsünüz:

Loglarda Out of memory: Kill process ... Mesajları: En net belirti, sistem çekirdek loglarında (genellikle dmesg çıktısı veya /var/log/syslog, /var/log/messages dosyalarında) OOM Killer’ın hangi süreci sonlandırdığını belirten mesajlardır. Bu mesajlar, sorunun kökenini anlamak için kritik bilgiler içerir.
Ani Uygulama Çökmeleri: Uygulamalarınızın herhangi bir hata mesajı veya stack trace bırakmadan aniden kapanması. Bu, OOM Killer’ın SIGKILL göndermesinin tipik bir sonucudur.
Sistem Donmaları veya Yavaşlamaları: OOM Killer devreye girmeden hemen önce, sistem aşırı bellek ve swap kullanımı nedeniyle ciddi şekilde yavaşlayabilir veya geçici olarak donabilir. Bu durum, disk I/O’sunun aşırı yüklenmesiyle de ilişkilidir.

Bu belirtileri gözlemlediğinizde, OOM Killer’ın sisteminizde aktif olduğunu ve bellek yönetimi sorunları yaşadığınızı anlamalısınız.

RAM Aşımını Tespit Etme ve Teşhis Etme

RAM aşımını ve OOM Killer’ın neden olduğu sorunları tespit etmek ve teşhis etmek, doğru araçları ve yöntemleri kullanmayı gerektirir. Erken teşhis, büyük üretim kesintilerini önlemenin anahtarıdır.

Sistem Logları

Sistem logları, OOM Killer’ın devreye girdiğini gösteren en güvenilir kaynaklardır.

dmesg: Çekirdek mesajlarını gösterir. OOM Killer, çekirdek tarafından tetiklendiği için dmesg çıktısında mutlaka yer alır.
```
dmesg | grep -i "oom-killer"
dmesg | grep -i "out of memory"
```
Bu komutlar, OOM Killer’ın ne zaman tetiklendiğini, hangi süreci sonlandırdığını ve ilgili bellek istatistiklerini gösteren mesajları filtrelemenize yardımcı olur. Genellikle şu formatta bir çıktı görürsünüz:
```
[12345.678901] Out of memory: Kill process 1234 (my_app) score 987 or sacrifice child
[12345.678901] Killed process 1234 (my_app) total-vm:4000000kB, anon-rss:3000000kB, file-rss:10000kB
```
/var/log/syslog veya /var/log/messages: Genel sistem log dosyalarıdır ve çekirdek mesajlarını da içerir. Dağıtıma göre yolu değişebilir.
```
grep -i "oom-killer" /var/log/syslog
grep -i "out of memory" /var/log/messages
```
Bu logları düzenli olarak kontrol etmek, OOM Killer’ın ne zaman ve hangi koşullar altında tetiklendiğini anlamanıza yardımcı olacaktır.

Bellek Kullanımı İzleme Araçları

Gerçek zamanlı ve geçmiş bellek kullanımını izlemek, potansiyel RAM aşımı sorunlarını önceden tespit etmek için önemlidir.

top ve htop: En temel ve en sık kullanılan araçlardır. Sistemdeki mevcut süreçlerin bellek ve CPU kullanımını gösterirler. RES (Resident Set Size) bir sürecin fiziksel RAM’de ne kadar yer kapladığını, VIRT (Virtual Memory Size) ise sürecin sanal bellek boyutunu gösterir. htop, top’ın daha kullanıcı dostu ve renkli bir versiyonudur.
```
top
htop
```
free -h: Toplam, kullanılan ve boş fiziksel RAM ile swap alanı hakkında özet bilgi verir. -h bayrağı, çıktıyı insan tarafından okunabilir (human-readable) formatta gösterir.
```
free -h
```
Bu komutun çıktısı, özellikle “available” (kullanılabilir) bellek miktarını ve “swap” kullanımını kontrol etmek için faydalıdır. Swap kullanımı sürekli artıyorsa veya çok yüksekse, bu bir bellek sorununun habercisi olabilir.
vmstat: Sanal bellek, disk, tuzak ve CPU aktivitesi hakkında raporlar sağlar. Özellikle si (swap in) ve so (swap out) sütunları, diskten ve diske yapılan swap işlemlerinin miktarını gösterir. Yüksek si ve so değerleri, sistemin yoğun bir şekilde swap kullandığını ve bellek baskısı altında olduğunu gösterir.
```
vmstat 1 # Her 1 saniyede bir rapor gösterir
```
sar (System Activity Reporter): Geçmiş sistem aktivitesi verilerini toplar ve raporlar. Bellek kullanımı da dahil olmak üzere birçok metrik için geçmiş verileri incelemenize olanak tanır.
```
sar -r # Bellek kullanım raporu
sar -S # Swap alanı kullanım raporu
```
sar özellikle belirli bir zaman dilimindeki bellek kullanım eğilimlerini anlamak için çok değerlidir.
Prometheus/Grafana, Datadog, New Relic gibi Monitoring Araçları: Kurumsal seviyede, bu araçlar sunucularınızdaki bellek kullanımını gerçek zamanlı olarak izlemenizi ve geçmiş verileri görselleştirmenizi sağlar. Belirli eşik değerleri aşıldığında uyarılar kurarak potansiyel sorunları önceden tespit edebilirsiniz. Bu tür araçlar, bellek sızıntıları gibi zamanla yavaşça gelişen sorunları görselleştirerek tespit etmede son derece etkilidir.

Uygulama İçi Metrikler

Uygulama düzeyinde bellek kullanımı takibi, sorunun kaynağını daha spesifik olarak belirlemenize yardımcı olabilir.

JVM GC Logları (Java): Java uygulamalarında, Garbage Collector (GC) logları bellek tahsisi, boşaltılması ve GC döngüleri hakkında ayrıntılı bilgi sağlar. Artan GC süresi veya tam GC döngülerinin sıklaşması, bir bellek sızıntısına veya verimsiz bellek kullanımına işaret edebilir.
```
# JVM başlatılırken eklenecek argümanlar
java -Xmx4G -Xms4G -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/var/log/my_app_gc.log -jar my_app.jar
```
.NET Memory Profilers: Visual Studio Profiler veya JetBrains dotMemory gibi araçlar, .NET uygulamalarındaki bellek tüketimini, nesne yaşam döngülerini ve potansiyel sızıntıları analiz etmek için kullanılır.
Python memory_profiler: Python uygulamalarında satır bazında bellek kullanımını analiz etmek için kullanılabilen bir kütüphanedir.
```
pip install memory_profiler
python -m memory_profiler your_script.py
```
Request/Response Boyutları: Özellikle API servislerinde, gelen request payload’larının veya giden response payload’larının beklenenden çok büyük olması, anlık bellek tüketimini artırabilir. Bu tür durumları izlemek için web sunucusu loglarını veya uygulama içi metrikleri kullanabilirsiniz.

OOM Killer’dan Korunma ve Önleme Stratejileri

RAM aşımı ve OOM Killer sorunlarını önlemek için hem uygulama seviyesinde hem de sistem seviyesinde çeşitli stratejiler mevcuttur. Bu stratejilerin bir kombinasyonunu uygulamak, sistemlerinizin daha dayanıklı ve kararlı olmasını sağlayacaktır.

Uygulama Seviyesi Optimizasyonlar

Uygulama kodundaki ve mimarisindeki iyileştirmeler, bellek tüketimini doğrudan azaltmanın en etkili yollarından biridir.

Bellek Sızıntılarını Giderme: Kodunuzu düzenli olarak bellek sızıntıları açısından profilleyin ve test edin. Özellikle uzun süre çalışan servisler (web sunucuları, arka plan işleyicileri) için bu kritik öneme sahiptir. Profilleme araçları ve statik analiz, bu tür sorunları tespit etmede yardımcı olabilir.
Verimli Veri Yapıları Kullanma: Bellek dostu veri yapıları ve algoritmalar seçin. Örneğin, büyük bir listeyi sürekli olarak kopyalamak yerine, iteratörler veya generator’lar kullanmak bellekte büyük kazançlar sağlayabilir. Hash map’ler yerine daha az bellek tüketen alternatifleri değerlendirin.
Sınırlı Kaynak Kullanımı (Connection Pools, Thread Pools): Veritabanı bağlantıları, HTTP bağlantıları veya iş parçacıkları gibi kaynakların sayısını sınırlamak için pool’lar kullanın. Bu, aynı anda açılabilecek bağlantı veya iş parçacığı sayısını kontrol ederek bellek tüketimini yönetmeye yardımcı olur. Sınırsız kaynak tahsisi, ani yük artışlarında hızla bellek aşımına yol açabilir.
Asenkron İşlemler: Yoğun I/O işlemleri (veritabanı sorguları, ağ istekleri) için asenkron programlama modellerini tercih edin. Bu, aynı anda daha fazla isteği daha az iş parçacığı ve dolayısıyla daha az bellek ile işlemenizi sağlar. Geleneksel senkron modelde her bağlantı için bir iş parçacığı ve onun bellek yükü gerekirken, asenkron model olay döngüsüyle çok daha verimli çalışabilir.
Gereksiz Bağımlılıkları Azaltma: Uygulamanızın kullandığı kütüphane ve modül sayısını gözden geçirin. Her bağımlılık, uygulamanızın bellek ayak izini artırır. Gerçekten ihtiyacınız olmayan bağımlılıklardan kurtulmak, bellek kullanımını optimize edebilir.

Sistem Seviyesi Ayarlamalar

İşletim sistemi ayarları ve çekirdek parametreleri, RAM aşımını yönetmede önemli rol oynar.

Swap Alanı Yönetimi (swappiness): swappiness parametresi (0-100 arası), Linux çekirdeğinin ne kadar agresif bir şekilde swap alanını kullanacağını belirler. Yüksek bir değer (varsayılan 60), çekirdeğin daha erken swap’e başlamasına neden olur. Daha düşük bir değer (örneğin 10 veya 0), çekirdeğin fiziksel RAM’i daha uzun süre kullanmasını sağlar ve swap’e gitmeyi geciktirir. Genellikle sunucular için swappiness’i düşük tutmak iyi bir uygulamadır.
```
# Mevcut swappiness değerini görmek için:
cat /proc/sys/vm/swappiness

# swappiness değerini 10 olarak ayarlamak için (geçici):
sudo sysctl vm.swappiness=10

# Kalıcı yapmak için /etc/sysctl.conf dosyasına ekleyin:
echo "vm.swappiness = 10" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p # Değişiklikleri uygulamak için
```
Cgroup’lar ile Kaynak Limitleri (memory.limit_in_bytes): Control Groups (cgroups), Linux’ta süreç gruplarına kaynak limitleri atamanıza olanak tanır. Bellek limitleri belirleyerek, bir uygulamanın veya servis grubunun belirli bir bellek miktarından fazlasını kullanmasını engelleyebilirsiniz. Bu, bir uygulamanın bellek sızıntısı durumunda tüm sistemi çökertmesini önler. Docker ve Kubernetes gibi konteyner teknolojileri, arka planda cgroup’ları kullanarak kaynak limitleri uygular.
```
# Bir cgroup oluşturma ve bellek limiti atama örneği
sudo mkdir /sys/fs/cgroup/memory/my_app_group
sudo sh -c "echo 512M > /sys/fs/cgroup/memory/my_app_group/memory.limit_in_bytes"
sudo sh -c "echo <PID> > /sys/fs/cgroup/memory/my_app_group/tasks"
```
oom_score_adj ile Önceliklendirme: Daha önce bahsedildiği gibi, kritik süreçler için oom_score_adj değerini -1000 olarak ayarlayarak OOM Killer tarafından sonlandırılma olasılıklarını azaltabilirsiniz. Bu, sistem çökerken en azından temel hizmetlerin ayakta kalmasını sağlar.
Overcommit Ayarları (vm.overcommit_memory): Linux çekirdeği, bellek talep eden bir sürece, gerçekten ihtiyacı olandan daha fazla bellek tahsis edebileceğini varsayabilir. Bu, “memory overcommit” olarak bilinir. vm.overcommit_memory parametresi bu davranışı kontrol eder:
- 0 (varsayılan): Sezgisel overcommit. Çekirdek, bellek tahsisine izin vermeden önce yeterli bellek olup olmadığını tahmin etmeye çalışır.
- 1: Her zaman overcommit. Çekirdek, herhangi bir bellek tahsis isteğini kabul eder, fiziksel bellek olup olmadığını kontrol etmez. Bu, OOM Killer’ı daha sık tetikleyebilir.
- 2: Asla overcommit. Çekirdek, vm.overcommit_ratio tarafından belirlenen miktardan daha fazla bellek tahsis etmeyi reddeder. Bu ayar, OOM Killer’ı nadiren tetikler ancak bellek tahsis hatalarına yol açabilir. Genellikle 2 değeri, kritik ve bellek hassasiyeti yüksek sunucular için tercih edilir.
```
# vm.overcommit_memory değerini 2 olarak ayarlamak (geçici):
sudo sysctl vm.overcommit_memory=2

# Kalıcı yapmak için /etc/sysctl.conf dosyasına ekleyin:
echo "vm.overcommit_memory = 2" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p
```
Bellek Miktarını Artırma: En basit ve bazen kaçınılmaz çözüm, sunucuya daha fazla fiziksel RAM eklemektir. Özellikle uygulama optimizasyonları veya yapılandırma ayarlamaları yeterli olmadığında, bu geçici veya kalıcı bir çözüm olabilir.

Altyapı ve Mimari İyileştirmeler

Uygulamanızın çalıştığı altyapı ve genel mimari, bellek sorunlarını yönetmede büyük fark yaratabilir.

Microservices Mimarisi: Büyük, monolitik bir uygulamayı daha küçük, bağımsız microservice’lere bölmek, her servisin kendi bellek alanına sahip olmasını sağlar. Bu sayede bir servisteki bellek sızıntısı veya aşırı bellek tüketimi, tüm sistemi çökertmek yerine sadece o servisi etkiler.
Yük Dengeleme ve Yatay Ölçekleme: Gelen isteği birden fazla sunucuya dağıtan bir yük dengeleyici kullanın. Ardından, talep arttığında uygulama örneklerini yatay olarak ölçeklendirin (yani daha fazla sunucu ekleyin). Bu, tek bir sunucu üzerindeki bellek yükünü azaltır ve OOM Killer riskini düşürür.
Önbellekleme Mekanizmaları (CDN, Redis): Sık erişilen verileri önbelleğe almak, ana uygulamanın veritabanına veya arka uç servislere daha az istek göndermesini sağlar. Bu, hem CPU hem de bellek kullanımını azaltır. CDN’ler (Content Delivery Network) statik içerik için, Redis veya Memcached gibi in-memory cache’ler ise dinamik veri önbelleklemesi için kullanılabilir.
Queue Sistemleri (RabbitMQ, Kafka): Yoğun ve zaman alıcı işlemleri doğrudan ana uygulama üzerinden yapmak yerine, bir mesaj kuyruğuna (message queue) gönderin. Arka plan worker’ları bu kuyruktan işleri alıp asenkron olarak işleyebilir. Bu, web sunucusunun veya API’nin bellek yükünü önemli ölçüde azaltır ve talebin ani yükselişlerinde sistemin daha kararlı kalmasını sağlar.

Vaka Çalışması: Üretim Ortamında OOM Killer ile Mücadele

Bir e-ticaret platformunun Node.js tabanlı API servisinde yaşanan bir OOM Killer vakasını ele alalım.

Senaryo: API servisi, belirli saatlerde (örneğin indirim dönemlerinde) yoğun trafik aldığında aniden çökmeye başlıyor. Uygulama loglarında herhangi bir hata olmamasına rağmen, servis restart ediliyor ve kısa bir süre sonra tekrar çöküyor. Müşteriler, “502 Bad Gateway” veya “Service Unavailable” hataları alıyorlar.

Teşhis Adımları:

Sistem Loglarını Kontrol Etme: Sunucuda dmesg | grep -i "oom" komutu çalıştırıldığında, aşağıdaki gibi çıktılar görülüyor:
```
[12345.678901] Out of memory: Kill process 5678 (node) score 950 or sacrifice child
[12345.678901] Killed process 5678 (node) total-vm:8GB, anon-rss:7.5GB, file-rss:0kB
```
Bu, Node.js sürecinin OOM Killer tarafından sonlandırıldığını açıkça gösteriyor.
Bellek Kullanımı İzleme: htop ve free -h komutlarıyla

RAM Aşımı ve OOM Killer: Üretimde Ani Çöküşler Nasıl Önlenir?