Yükleniyor
Konteyner ve mikroservislerinizin ani bellek siçramalarinda habersizce oldurulmesini (OOM Kill) engelleyin. Linux cgroups v2 memory.high proaktif frenleme mekanizmasi ile bellek garantilerini (min, low, high, max) ve atomik itlaf kurallarini hesaplayin.
Sert bellek garantisi. Diger surecler sisip sunucu sikissa bile cekirdek bu alani asla geri alamaz (reclaim etmez).
Yumusak koruma. Sunucuda baska bos bellek oldugu surece bu alan korunur; ancak ciddi sistem krizinde reclaim edilebilir.
Proaktif frenleme (Throttling) esigi. Asildiginda OOM Killer tetiklenmez; cekirdek surecin bellek tahsisini yavaslatir ve arka planda temizlik yapar.
Azami sinir (Hard Limit). Bu esik asildiginda ve reclaim yetersiz kaldiginda cgroup OOM Killer calisarak sureci sonlandirir.
/etc/systemd/system/myapp.service.d/override.conf icin MemoryHigh ve MemoryOOMGroup tanimlari.
# /etc/systemd/system/myapp.service.d/override.conf # Systemd cgroups v2 Bellek QoS Guvenlik Profili [Service] # Kesin garanti bellek MemoryMin=512M # Yumusak efor garantisi MemoryLow=1229M # Proaktif frenleme esigi (OOM onleyici) MemoryHigh=1782M # Sert tepe siniri MemoryMax=2048M # Swap tavani MemorySwapMax=717M # OOM durumunda tum alt surecleri tek seferde temizce oldur (zombi process kalmasin) MemoryOOMGroup=true
Docker Daemon v26+ cgroup v2 etiketleri ve deploy limitleri.
# 2026 cgroups v2 Destekli Docker Compose Yapilandirmasi
# docker-compose.yml
services:
app:
image: myapp:latest
restart: unless-stopped
deploy:
resources:
limits:
memory: 2048M
# cgroups v2 ince ayarlar (sysfs dogrudan baglanti)
sysctls:
- net.core.somaxconn=1024
# Docker Daemon v26+ cgroup v2 parametreleri
labels:
- "cgroup.memory.min=536870912"
- "cgroup.memory.low=1288699904"
- "cgroup.memory.high=1868562432"
- "cgroup.memory.max=2147483648"
- "cgroup.memory.oom.group=1"Klasik Linux cgroups v1 mimarisinde yalnizca tek bir sert limit (memory.limit_in_bytes) bulunmaktaydi. Bir servis (Node.js, Java, Python veya PHP-FPM) bu sınıra ulastigi milisaniyede kernel OOM Killer devreye girerek servisi haber vermeksizin oldururdu. 2026 yilinda tum modern dagitimlarin (Ubuntu 24.04+, Debian 12+, RHEL 9+) varsayilani olancgroups v2 ise 4 kademeli bir Bellek Hizmet Kalitesi (Memory Quality of Service - QoS) modeli getirmistir.
cgroups v2'nin en buyuk devrimi memory.high parametresidir. Konteynerin bellek kullanimi bu esigi astiginda, cekirdek surecleri derhal oldurmez. Bunun yerine bellek talep eden is parcaciklarina gecikme (allocation delay) ekleyerek onlari frenler (throttle eder) ve arkada sayfa onbellegini (page cache) ya da swap alanini bosaltmaya zorlar. Bu sayede OOM krizleri birer performans dalgalanmasina donusturulerek servisin canli kalmasi saglanir.
Varsayilan memory.oom.group = 0 ayarinda Linux, cgroup icindeki en cok RAM tuketen tek bir sureci oldurur. Ornegin bir Nginx veya Celery konteynerinde ana surec ayakta kalirken worker surecleri olur ve konteyner disaridan calisiyor gorunse de istekleri yanitlayamaz (zombie state).memory.oom.group = 1 yapildiginda ise tum konteyner atomik olarak temizce sonlandirilir ve Docker / Kubernetes servisi sifirdan saglikli sekilde yeniden baslatir.
memory.min, sunucudaki diger islemler ne kadar RAM tuketirse tuketsin, isletim sisteminin ASLA geri alamayacagi kesin rezerve alandir. Veritabanlarinin ana buffer pool'u icin hayati onem tasir.memory.low ise yumusak bir garantidir; diger cgroup'lar bos bellege sahip oldugu surece bu alan korunur, ancak tum sunucu kritik bellek krizine girerse kontrollu sekilde geri alinabilir.
cgroups v2, sistem yoneticilerine memory.pressure dosyasini sunar.some avg10 ve full avg10metrikleri, sureclerin bellek beklemesi yuzunden CPU'da ne kadar sure bloke kaldigini gosterir. PSI degeri yukseldiginde servis henuz OOM almadan once yatay olcekleme (auto-scaling) yapilabilir.