- Konu sahibi
- #1
OOM Killer, Linux çekirdeği yeni bir bellek tahsisini karşılayamadığında ve kullanılabilir belleği geri kazanamadığında devreye girer. En doğru yaklaşım, önce hangi sürecin ne zaman öldürüldüğünü günlüklerden doğrulamak, ardından fiziksel RAM, swap, süreç tüketimi ve varsa cgroup/container bellek limitlerini ayrı ayrı incelemektir. Sorun sürekli yaşanıyorsa yalnızca daha fazla swap eklemek yerine bellek tüketen sürecin nedenini düzeltmeli, servis limitlerini gözden geçirmeli ve sunucunun gerçek çalışma yüküne göre RAM planlamalısınız.
OOM Killer, “bellek tamamen sıfıra indi” anlamına gelen basit bir sayaç değildir. Çekirdek, bir işlem için gerekli bellek tahsisini yapmaya çalışırken kullanılabilir sayfaları geri kazanamazsa, swap alanına taşıma yeterli olmazsa veya ilgili bellek limiti aşılırsa bir süreci sonlandırarak sistemi çalışır durumda tutmaya çalışır.
Bu durum genellikle aşağıdaki nedenlerden biriyle oluşur:
Sorun tekrar yaşandığında ilk olarak çekirdek ve servis günlüklerinde OOM kayıtlarını arayın. İşlemleri root yetkisiyle veya günlükleri okuyabilecek yetkiyle çalıştırın:
Çıktıda “Out of memory”, “oom-kill” veya “Killed process” benzeri bir kayıt görürseniz Linux çekirdeğinin bir süreci bellek baskısı nedeniyle sonlandırdığı doğrulanır. Aynı kayıtta öldürülen sürecin adı, işlem kimliği ve bazı bellek bilgileri bulunabilir.
Ancak öldürülen süreç her zaman sorunun asıl kaynağı değildir. Çekirdek, o anda sonlandırılması daha uygun görünen süreci seçebilir. Örneğin OOM kaydında PHP-FPM öldürülmüş olabilir; fakat bellek baskısını oluşturan neden çok sayıda PHP worker’ı, hatalı bir eklenti, yoğun bir sorgu veya aynı anda çalışan başka bir servis olabilir.
Günlüklerde OOM kaydı yoksa yalnızca bir servisin kapanmış olması OOM Killer’ı kanıtlamaz. Servisin kendi hata günlüğünü, systemd durumunu ve uygulama kayıtlarını ayrıca kontrol edin:
Anlık tüketimi görmek için aşağıdaki komutlardan yararlanabilirsiniz:
Sorun zaman içinde büyüyorsa anlık liste yeterli değildir. Belirli aralıklarla kayıt alarak hangi sürecin yükseldiğini izleyin:
Bu örneği durdurmak için
OOM nedenini doğru belirlemek için aşağıdaki durumları ayrı değerlendirin.
Bu ayrım önemlidir; çünkü host RAM’ini artırmak, düşük bir container limitinden kaynaklanan OOM olayını tek başına çözmez. Tersine, yalnızca cgroup limitini yükseltmek de fiziksel RAM yetersizse host seviyesindeki OOM olayını ortadan kaldırmaz.
Önce en çok RAM kullanan servisleri ve bunların çalışma biçimini belirleyin. Web sunucularında PHP-FPM worker sayısı, uygulama sunucularında worker veya thread sayısı, veritabanlarında önbellek ve bağlantı limitleri, Java uygulamalarında heap ayarları, Node.js uygulamalarında süreç sayısı ve container limitleri birlikte değerlendirilmelidir.
Bir servisin bellek ayarını artırmak, o servisi hızlandırabilir; ancak sunucunun geri kalan servisleri için daha az RAM bırakır. Bu nedenle hedef, tek bir servise mümkün olan en yüksek değeri vermek değil, bütün servislerin toplam tepe tüketimini fiziksel RAM ve işletim sistemi payıyla birlikte kapasite içinde tutmaktır.
Her worker’ın ortalama veya tepe RSS tüketimini ölçün. Ardından varsayımsal bir üst sınır hesabı yapın:
Bu bir kapasite tahminidir; paylaşılan bellek, önbellek ve kısa süreli tepe kullanımlar nedeniyle kesin garanti vermez. Hesap sonucunda RAM’in tamamını servisler arasında dağıtmayın. Dosya önbelleği, çekirdek, izleme, SSH, yedekleme ve beklenmeyen trafik için pay bırakın.
Worker sayısını azaltmak OOM riskini düşürebilir; fakat çok fazla azaltılırsa istek kuyruğu ve yanıt süresi artabilir. Değişiklikten sonra yoğunluk sırasında 5xx oranını, yanıt süresini, kuyrukları ve bellek kullanımını birlikte izleyin.
Tek bir süreç saatler içinde sürekli büyüyorsa sorunu yalnızca servisi periyodik olarak yeniden başlatarak gizlemeyin. Geçici yeniden başlatma, belleği geri kazandırabilir; fakat sızıntının nedenini çözmez ve yeniden başlatma sırasında kısa süreli hizmet kesintisi oluşturabilir.
İncelemede şu bilgileri aynı zaman aralığıyla eşleştirin:
Swap, kullanılmayan bellek sayfalarının diskte tutulmasına izin verir ve kısa süreli bellek tepe noktalarında OOM riskini azaltabilir. Ancak RAM’in yerine geçmez. Swap kullanımı sürekli yüksekse sistem disk beklemelerine girebilir ve uygulama yanıtları ciddi biçimde yavaşlayabilir.
Mevcut durumu kontrol edin:
Swap yoksa veya çok küçükse, önce sunucunun disk türünü, depolama performansını ve barındırma sağlayıcısının sanallaştırma kısıtlarını kontrol edin. Swap dosyası oluşturma ve etkinleştirme adımları dağıtıma, dosya sistemi özelliklerine ve sağlayıcı politikasına göre değişebilir; bu nedenle kullanılan dağıtımın resmî yöntemini uygulayın.
Swap eklemek günlüklerdeki OOM kaydını hemen ortadan kaldırmayabilir. Uygulama kısa sürede RAM ve swap’ın tamamını tüketiyorsa temel sorun kapasite veya süreç davranışıdır. Swap’ın amacı, sınırlı ve geçici bellek baskısında tampon olmaktır; sürekli kapasite açığını kapatmak değildir.
Container kullanıyorsanız host belleğini ve container’ın kendi kullanımını ayrı izleyin. Docker veya başka bir container yöneticisinde tanımlı bellek limiti, host’ta boş RAM olsa bile container içindeki OOM olayını tetikleyebilir.
systemd ile çalışan servislerde de kaynak kontrolü uygulanmış olabilir. Servisin hangi cgroup içinde çalıştığını ve limitlerinin nereden geldiğini kullandığınız dağıtımın yapılandırmasına göre kontrol edin. Limit düşükse artırmadan önce host’un toplam kapasitesini hesaplayın; bir servisin limitini yükseltmek diğer servisler için ayrılan belleği azaltabilir.
Linux’ta bellek taahhüdü, süreçlerin istediği sanal belleğin ne zaman fiziksel RAM veya swap ile destekleneceğiyle ilgilidir.
Bu ayarlar ancak uygulamanın bellek tahsis davranışı, swap kapasitesi, çekirdek sürümü ve iş yükü bilinerek değiştirilmelidir. Önce mevcut değeri ve uygulamanın aldığı hatayı kaydedin; değişiklikten sonra servislerin başlatılması, bellek tahsisi ve OOM günlüklerini izleyin. Sorun yalnızca normal RAM tepe kullanımından kaynaklanıyorsa kernel ayarını değiştirmek yerine kapasite ve servis ayarlarını düzeltmek daha doğrudur.
Varsayımsal bir günlükte şu tür bilgiler bulunduğunu düşünün:
Bu kayıt,
Bir container günlükte OOMKilled olarak görünüyorsa host RAM’i normal olsa bile container limitini kontrol edin. Limit artırıldığında host’un kullanılabilir belleği yetersiz kalıyorsa bu kez host seviyesinde yeni bir OOM olayı yaşanabilir; bu nedenle iki katmanı birlikte izlemek gerekir.
OOM olayını tekrar gördüğünüzde aşağıdaki sırayı izleyin:
OOM Killer hangi durumda devreye girer?
OOM Killer, “bellek tamamen sıfıra indi” anlamına gelen basit bir sayaç değildir. Çekirdek, bir işlem için gerekli bellek tahsisini yapmaya çalışırken kullanılabilir sayfaları geri kazanamazsa, swap alanına taşıma yeterli olmazsa veya ilgili bellek limiti aşılırsa bir süreci sonlandırarak sistemi çalışır durumda tutmaya çalışır.
Bu durum genellikle aşağıdaki nedenlerden biriyle oluşur:
- Sunucudaki fiziksel RAM, çalışan servislerin toplam ihtiyacını karşılamıyordur.
- Swap yoktur, çok küçüktür veya yoğun bellek baskısı altında yeterli destek sağlayamıyordur.
- Bir uygulamada bellek sızıntısı vardır ve süreç zamanla büyüyordur.
- Veritabanı, PHP-FPM, Java, Node.js veya başka bir servis için ayrılan bellek, sunucunun gerçek kapasitesine göre fazla ayarlanmıştır.
- Docker, systemd veya başka bir cgroup katmanında tanımlanan bellek limiti aşılmıştır.
- Aynı fiziksel sunucuda çok sayıda site, worker, cron görevi veya yedekleme işlemi aynı anda çalışıyordur.
free -h çıktısına bakmak yeterli değildir.Önce gerçekten OOM olayı olduğunu doğrulayın
Sorun tekrar yaşandığında ilk olarak çekirdek ve servis günlüklerinde OOM kayıtlarını arayın. İşlemleri root yetkisiyle veya günlükleri okuyabilecek yetkiyle çalıştırın:
Bash:
dmesg -T | grep -i -E 'out of memory|oom|killed process'
journalctl -k -b | grep -i -E 'out of memory|oom|killed process'
free -h
cat /proc/meminfoÇıktıda “Out of memory”, “oom-kill” veya “Killed process” benzeri bir kayıt görürseniz Linux çekirdeğinin bir süreci bellek baskısı nedeniyle sonlandırdığı doğrulanır. Aynı kayıtta öldürülen sürecin adı, işlem kimliği ve bazı bellek bilgileri bulunabilir.
Ancak öldürülen süreç her zaman sorunun asıl kaynağı değildir. Çekirdek, o anda sonlandırılması daha uygun görünen süreci seçebilir. Örneğin OOM kaydında PHP-FPM öldürülmüş olabilir; fakat bellek baskısını oluşturan neden çok sayıda PHP worker’ı, hatalı bir eklenti, yoğun bir sorgu veya aynı anda çalışan başka bir servis olabilir.
Günlüklerde OOM kaydı yoksa yalnızca bir servisin kapanmış olması OOM Killer’ı kanıtlamaz. Servisin kendi hata günlüğünü, systemd durumunu ve uygulama kayıtlarını ayrıca kontrol edin:
Bash:
systemctl status servis-adi
journalctl -u servis-adi --since '1 hour ago'servis-adi yerine sorun yaşanan gerçek servis adını yazın. Servis “killed”, “signal 9” veya benzeri bir sonuçla kapanmış olabilir; fakat bu bilgi tek başına OOM kanıtı değildir. Çekirdek günlüklerinde bellek baskısı kaydıyla birlikte görülmesi gerekir.Belleği hangi süreç tüketiyor?
Anlık tüketimi görmek için aşağıdaki komutlardan yararlanabilirsiniz:
Bash:
free -h
ps aux --sort=-%mem | head -n 15
ps -eo pid,ppid,comm,%mem,rss,vsz --sort=-rss | head -n 15free -h toplam RAM’i, kullanılan belleği, kullanılabilir belleği ve swap durumunu özetler. Linux’un dosya önbelleği için RAM kullanması normaldir; “used” değerinin yüksek olması tek başına bellek bittiği anlamına gelmez. Özellikle available değerine ve swap kullanımının zaman içinde artıp artmadığına bakın.ps çıktısında aynı uygulamaya ait çok sayıda worker görürseniz toplam tüketimi tek bir worker’ın değeriyle karıştırmayın. Örneğin varsayımsal olarak her PHP-FPM worker’ı yaklaşık 120 MB RSS kullanıyor ve aynı anda 40 worker çalışıyorsa yalnızca bu worker’ların kaba toplamı yaklaşık 4,8 GB olur. Paylaşılan bellek nedeniyle bu hesap kesin sonuç vermez; fakat worker sayısının RAM planlamasındaki etkisini gösterir.Sorun zaman içinde büyüyorsa anlık liste yeterli değildir. Belirli aralıklarla kayıt alarak hangi sürecin yükseldiğini izleyin:
Bash:
while sleep 10; do
date
free -h
ps -eo pid,comm,%mem,rss --sort=-rss | head -n 10
doneBu örneği durdurmak için
Ctrl+C kullanın. RSS değeri sürekli yükselen tek bir süreç varsa bellek sızıntısı veya sınırsız büyüyen bir iş yükü araştırılmalıdır. Aynı anda worker sayısı artıyorsa sorun tek bir süreçteki sızıntıdan çok paralellik veya kuyruk ayarlarıyla ilgili olabilir.RAM, swap ve cgroup limitini birbirinden ayırın
OOM nedenini doğru belirlemek için aşağıdaki durumları ayrı değerlendirin.
| Gözlenen durum | Ne anlama gelebilir? | İlk sonraki işlem |
|---|---|---|
| Host RAM’i ve available değeri düşüyor, swap da doluyor | Toplam bellek ihtiyacı fiziksel kapasiteyi aşmış olabilir | En çok tüketen servisleri ve eşzamanlı worker sayılarını inceleyin |
| Host’ta RAM var, container içinde OOM kaydı var | Container veya cgroup bellek limiti aşılmış olabilir | Limit, kullanım ve container olaylarını birlikte kontrol edin |
| Tek süreç zamanla büyüyor | Bellek sızıntısı veya serbest bırakılmayan uygulama verisi olasılığı vardır | Sürecin sürümünü, modüllerini, istek türünü ve yeniden başlatma davranışını inceleyin |
| Servis yalnızca yoğun saatlerde kapanıyor | Eşzamanlı istek, worker veya sorgu sayısı kapasiteyi aşıyor olabilir | Yoğunluk sırasında süreç sayısını ve istek başına bellek tüketimini ölçün |
| OOM kaydı yok, servis kapanıyor | Neden OOM olmayabilir; uygulama hatası, servis yöneticisi veya disk sorunu da mümkündür | Servis ve sistem günlüklerini aynı zaman aralığında karşılaştırın |
OOM Killer nasıl önlenir?
1. Gerçek tüketimi ölçmeden servis limitlerini yükseltmeyin
Önce en çok RAM kullanan servisleri ve bunların çalışma biçimini belirleyin. Web sunucularında PHP-FPM worker sayısı, uygulama sunucularında worker veya thread sayısı, veritabanlarında önbellek ve bağlantı limitleri, Java uygulamalarında heap ayarları, Node.js uygulamalarında süreç sayısı ve container limitleri birlikte değerlendirilmelidir.
Bir servisin bellek ayarını artırmak, o servisi hızlandırabilir; ancak sunucunun geri kalan servisleri için daha az RAM bırakır. Bu nedenle hedef, tek bir servise mümkün olan en yüksek değeri vermek değil, bütün servislerin toplam tepe tüketimini fiziksel RAM ve işletim sistemi payıyla birlikte kapasite içinde tutmaktır.
2. Worker ve eşzamanlılık sayılarını kapasiteye göre ayarlayın
Her worker’ın ortalama veya tepe RSS tüketimini ölçün. Ardından varsayımsal bir üst sınır hesabı yapın:
Kod:
Tahmini worker belleği = worker başına tepe bellek × worker sayısı
Toplam ihtiyaç = worker belleği + veritabanı + önbellek + diğer servisler + işletim sistemi payıBu bir kapasite tahminidir; paylaşılan bellek, önbellek ve kısa süreli tepe kullanımlar nedeniyle kesin garanti vermez. Hesap sonucunda RAM’in tamamını servisler arasında dağıtmayın. Dosya önbelleği, çekirdek, izleme, SSH, yedekleme ve beklenmeyen trafik için pay bırakın.
Worker sayısını azaltmak OOM riskini düşürebilir; fakat çok fazla azaltılırsa istek kuyruğu ve yanıt süresi artabilir. Değişiklikten sonra yoğunluk sırasında 5xx oranını, yanıt süresini, kuyrukları ve bellek kullanımını birlikte izleyin.
3. Bellek sızıntısı veya sınırsız büyümeyi araştırın
Tek bir süreç saatler içinde sürekli büyüyorsa sorunu yalnızca servisi periyodik olarak yeniden başlatarak gizlemeyin. Geçici yeniden başlatma, belleği geri kazandırabilir; fakat sızıntının nedenini çözmez ve yeniden başlatma sırasında kısa süreli hizmet kesintisi oluşturabilir.
İncelemede şu bilgileri aynı zaman aralığıyla eşleştirin:
- Sürecin PID’si ve RSS değerinin zamana göre değişimi.
- Uygulama sürümü, eklentiler ve son dağıtım değişiklikleri.
- Belirli URL, sorgu, dosya veya görev sonrasında bellek artışı olup olmadığı.
- Worker başına tüketim ile toplam worker sayısı.
- Servisin yeniden başlatılmasından sonra belleğin normale dönüp dönmediği.
4. Swap alanını yardımcı katman olarak kullanın
Swap, kullanılmayan bellek sayfalarının diskte tutulmasına izin verir ve kısa süreli bellek tepe noktalarında OOM riskini azaltabilir. Ancak RAM’in yerine geçmez. Swap kullanımı sürekli yüksekse sistem disk beklemelerine girebilir ve uygulama yanıtları ciddi biçimde yavaşlayabilir.
Mevcut durumu kontrol edin:
Bash:
swapon --show
free -h
cat /proc/sys/vm/swappinessSwap yoksa veya çok küçükse, önce sunucunun disk türünü, depolama performansını ve barındırma sağlayıcısının sanallaştırma kısıtlarını kontrol edin. Swap dosyası oluşturma ve etkinleştirme adımları dağıtıma, dosya sistemi özelliklerine ve sağlayıcı politikasına göre değişebilir; bu nedenle kullanılan dağıtımın resmî yöntemini uygulayın.
Swap eklemek günlüklerdeki OOM kaydını hemen ortadan kaldırmayabilir. Uygulama kısa sürede RAM ve swap’ın tamamını tüketiyorsa temel sorun kapasite veya süreç davranışıdır. Swap’ın amacı, sınırlı ve geçici bellek baskısında tampon olmaktır; sürekli kapasite açığını kapatmak değildir.
5. Container ve systemd bellek limitlerini kontrol edin
Container kullanıyorsanız host belleğini ve container’ın kendi kullanımını ayrı izleyin. Docker veya başka bir container yöneticisinde tanımlı bellek limiti, host’ta boş RAM olsa bile container içindeki OOM olayını tetikleyebilir.
systemd ile çalışan servislerde de kaynak kontrolü uygulanmış olabilir. Servisin hangi cgroup içinde çalıştığını ve limitlerinin nereden geldiğini kullandığınız dağıtımın yapılandırmasına göre kontrol edin. Limit düşükse artırmadan önce host’un toplam kapasitesini hesaplayın; bir servisin limitini yükseltmek diğer servisler için ayrılan belleği azaltabilir.
6. Bellek taahhüdü ve kernel ayarlarını bilinçli değiştirin
Linux’ta bellek taahhüdü, süreçlerin istediği sanal belleğin ne zaman fiziksel RAM veya swap ile destekleneceğiyle ilgilidir.
vm.overcommit_memory ve ilgili ayarlar değiştirilebilir; ancak bunları rastgele değiştirmek OOM sorununu çözmez. Yanlış bir değer, uygulamaların bellek tahsisini erken reddetmesine veya sistemin daha riskli bir duruma girmesine neden olabilir.Bu ayarlar ancak uygulamanın bellek tahsis davranışı, swap kapasitesi, çekirdek sürümü ve iş yükü bilinerek değiştirilmelidir. Önce mevcut değeri ve uygulamanın aldığı hatayı kaydedin; değişiklikten sonra servislerin başlatılması, bellek tahsisi ve OOM günlüklerini izleyin. Sorun yalnızca normal RAM tepe kullanımından kaynaklanıyorsa kernel ayarını değiştirmek yerine kapasite ve servis ayarlarını düzeltmek daha doğrudur.
Bir OOM kaydını nasıl yorumlayabilirsiniz?
Varsayımsal bir günlükte şu tür bilgiler bulunduğunu düşünün:
Kod:
Out of memory: Killed process 2481 (php-fpm) total-vm:... anon-rss:...Bu kayıt,
php-fpm sürecinin OOM olayı sırasında öldürüldüğünü gösterir. Şunları tek başına kanıtlamaz:- PHP-FPM’in kesin olarak bellek sızıntısı yaptığını.
- Sorunun yalnızca PHP ayarlarından kaynaklandığını.
- Sunucuya mutlaka daha fazla RAM eklenmesi gerektiğini.
Bir container günlükte OOMKilled olarak görünüyorsa host RAM’i normal olsa bile container limitini kontrol edin. Limit artırıldığında host’un kullanılabilir belleği yetersiz kalıyorsa bu kez host seviyesinde yeni bir OOM olayı yaşanabilir; bu nedenle iki katmanı birlikte izlemek gerekir.
Kalıcı çözüm için uygulanabilir kontrol sırası
OOM olayını tekrar gördüğünüzde aşağıdaki sırayı izleyin:
- Olayın saatini ve öldürülen PID ile süreç adını günlüklerden kaydedin.
- Aynı zaman aralığında
free -h,/proc/meminfo, swap durumu ve en çok RAM kullanan süreçleri inceleyin. - Sürecin tek başına büyüyüp büyümediğini veya worker sayısının topluca artıp artmadığını ayırın.
- Container, systemd veya başka bir cgroup bellek limiti olup olmadığını kontrol edin.
- Kısa süreli tepe kullanımını swap ve eşzamanlılık ayarlarıyla yönetin; sürekli yüksek kullanımı kapasite veya uygulama düzeltmesiyle ele alın.
- Değişikliği tek seferde ve ölçülebilir biçimde uygulayın; ardından OOM günlüklerini, yanıt sürelerini, hata oranını ve swap etkinliğini yeniden izleyin.
free -h çıktısı, swap durumu, container veya systemd limitleri, değişiklikten önceki ve sonraki worker sayısı ile servis günlüklerini ekleyin. Parolaları, kullanıcı verilerini ve hassas istek içeriklerini göndermeden bu bilgileri paylaşın. Böylece sorun RAM kapasitesi, servis yapılandırması, cgroup limiti veya uygulama davranışı olarak daha hızlı ayrıştırılabilir.Sık sorulan sorular
Swap kullanımı OOM Killer’ın kesin olarak devreye gireceği anlamına mı gelir?
Hayır. Swap kullanımı bellek baskısı olduğunu gösterebilir; fakat swap’ın bir bölümünün kullanılması tek başına OOM anlamına gelmez. RAM, swap ve süreç büyümesini birlikte izleyin. Swap sürekli doluyor ve sistem yavaşlıyorsa kapasite veya süreç tüketimi ayrıca ele alınmalıdır.
OOM Killer’ın öldürdüğü servisi yeniden başlatmak yeterli midir?
Yalnızca geçici bir toparlanma sağlayabilir. Servis yeniden başladıktan sonra bellek tekrar yükseliyorsa temel neden çözülmemiştir. Yeniden başlatma sonrasında süreç sayısını, RSS değerini, uygulama hatalarını ve OOM günlüklerini izleyerek sorunun tekrarlanıp tekrarlanmadığını belirleyin.
Sunucuda boş RAM görünüyorsa neden OOM yaşanabilir?
Bir container, systemd servisi veya başka bir cgroup kendi bellek limitini aşmış olabilir. Ayrıca olay anı geçmişse sonradan alınan
free -h çıktısı gerçek durumu göstermeyebilir. OOM kaydını olay saatindeki container ve servis limitleriyle birlikte inceleyin.Daha fazla RAM eklemek her zaman kalıcı çözüm müdür?
Hayır. RAM artışı kapasite yetersizliğini giderebilir; ancak bellek sızıntısı, sınırsız worker sayısı veya düşük cgroup limiti devam ederse sorun yeniden ortaya çıkabilir. Yeni kapasiteyi ekledikten sonra süreç başına tüketimi ve toplam tepe kullanımı yeniden ölçün.
