OOM katili çalışmıyor?

41

Anladığım kadarıyla, sistemin boş belleği olmaya yakın olduğunda, çekirdeğin bir miktar belleği geri kazanmak için işlemleri öldürmeye başlaması gerekir. Ama benim sistemimde bu hiç olmaz.

Sistemde mevcut olandan çok daha fazla bellek ayıran basit bir komut dosyası varsayalım (örneğin, milyonlarca dizeli bir dizi). Böyle bir betiği çalıştırırsam (normal bir kullanıcı olarak), sistem tamamen donuncaya kadar tüm belleği alır (sadece SysRQ REISUB çalışır).

Buradaki garip kısım, bilgisayar donduğunda, sabit sürücü ledinin yanması ve takma bölümünün takılı olması durumunda bilgisayar yeniden başlatılıncaya kadar devam etmesidir!

Yani benim sorularım:

Bu davranış normal mi? Normal bir kullanıcı olarak yürütülen bir uygulamanın sistemi bu şekilde çökertmesi garip ...
Çok fazla (veya en fazla) bellek elde ettiklerinde Ubuntu'nun bu uygulamaları otomatik olarak öldürmesini sağlayabilmemin bir yolu var mı?

Ek bilgi

Ubuntu 12.04.3
Çekirdek 3.5.0-44

RAM: ~ 4GB'tan 3,7GB (grafik kartı ile paylaşılan). *

$ tail -n+1 /proc/sys/vm/overcommit_*
==> /proc/sys/vm/overcommit_memory <==
0

==> /proc/sys/vm/overcommit_ratio <==
50

$ cat /proc/swaps
Filename                Type        Size    Used    Priority
/dev/dm-1                               partition   4194300 344696  -1

kernel

— Salem
kaynak

Neden işe yaramadığından emin değilim. tail -n+1 /proc/sys/vm/overcommit_*Çıktıyı deneyin ve ekleyin. Ayrıca bakınız: oom-katili nasıl yapılandırabilirim

— kiri

Peki takas alanınızla neler oluyor? #Vmstat 1 100 gibi bir vmstat çıktısı gönderebilir misiniz? ve ayrıca bize cat / etc / fstab komutunu gösterin. Ne olması gerektiği belli bir miktar hafıza kullanımında, takas için yazmaya başlamalısınız. Öldürme işlemleri bellek ve takas alanı "dolana" kadar olmamalıdır.

— j0h

ayrıca #swapon -a

— j0h

@ j0h Takas ile iyi çalışıyor gibi görünüyor (bir süre sonra süreç gibi bir şeyle düştü Allocation failed). Ancak takas olmadan sadece bilgisayarı dondurur. Bu şekilde çalışması gerekiyordu (sadece takas kullanırken öldür)?

— Salem

2

SysRq ile ayrıca OOM (SysRq + F iirc)

— Lekensteyn

36

Gönderen resmi /proc/sys/vm/*belgeler :

oom_kill_allocating_task

Bu, yetersiz bellek durumlarında OOM tetikleyici görevini öldürmeyi etkinleştirir veya devre dışı bırakır.

Eğer bu sıfıra ayarlanmışsa, OOM katili görev listesinin tamamını tarayacak ve öldürmek için sezgisel taramalara dayalı bir görev seçecektir. Bu normalde, öldürüldüğünde büyük miktarda belleği serbest bırakan sahte bellek takma görevini seçer.

Eğer bu sıfıra ayarlanmamışsa, OOM katili hafıza yetersizliği tetikleyen görevi basitçe öldürür. Bu, pahalı görev listesi taramasını engeller.

Panic_on_oom seçilirse, oom_kill_allocating_task öğesinde kullanılan değerden öncelikli olur.

Varsayılan değer 0'dır.

Ayarlarken, özetlenmesi amacıyla oom_kill_allocating_taskkadar 1yerine pahalı ve yavaş bir iştir öldürmek için süreçler arayan sistem, tarama, çekirdek sadece sistem belleği çıkmaya neden olan işlemi öldürecektir.

Kendi deneyimlerime göre, bir OOM tetiklendiğinde, çekirdeğin böyle bir tarama yapmak için yeterli "gücü" kalmaz ve sistemi tamamen kullanılamaz hale getirir.

Ayrıca, soruna neden olan görevi öldürmek daha açık olacaktır, bu yüzden neden 0varsayılan olarak ayarlandığını anlayamıyorum .

Test için, sadece bir /proc/sys/vm/sonraki açılışta geri alınacak olan uygun sahte dosyaya yazabilirsiniz :

echo 1 | sudo tee /proc/sys/vm/oom_kill_allocating_task

Kalıcı düzeltme için aşağıdaki bilgileri /etc/sysctl.confveya yeni bir dosya altındakiler için /etc/sysctl.d/bir ile, .conf(uzantısı /etc/sysctl.d/local.conförneğin):

vm.oom_kill_allocating_task = 1

— Teresa e Junior
kaynak

2

Ubuntu'da her zaman 0 olarak ayarlandı mı? Çünkü otomatik olarak öldürdüğünü hatırlıyorum, ancak birkaç versiyondan beri bunu yapmayı bıraktı.

— skerit

1

@skerit Bu gerçekten bilmiyorum, ancak 2010'da kullandığım çekirdeklerde (Debian, Liquorix ve GRML) 0 olarak ayarlandı.

— Teresa e Junior,

“Ayrıca, soruna neden olan görevi öldürmek daha açık olacaktır, bu nedenle neden 0varsayılan olarak ayarlandığını anlayamıyorum .” - Çünkü hafıza talep eden işlem mutlaka “soruna sebep olan” işlem değildir. A işlemi, sistem belleğinin% 99'unu atarsa, ancak% 0.9 kullanan B işlemi, OOM katilini kötü şansla tetikleyen bir süreçse, B "soruna neden olmaz" ve bunun bir anlamı olmaz. öldürmek B. Politika olarak farklı bir işlemin kaçak hafıza kullanımı nedeniyle tesadüfen öldürülen tamamen güvenli olmayan düşük bellek işlemlerinin risk altında olması .

— Mark Amery

1

@MarkAmery Asıl sorun, Linux'un sadece gerekli işlemi öldürmek yerine, gerizekalı gibi çökmeye başlaması vm.admin_reserve_kbytes, yani 128 MB'a yükseltilmiş olması . Ayar vm.oom_kill_allocating_task = 1sorunu hafifletiyor gibi görünüyor, gerçekten çözemiyor (ve Ubuntu zaten çatal bombalarla uğraşıyor).

— Teresa e Junior

1

Belki daha zarifsudo sysctl -w vm.oom_kill_allocating_task=1

— Pablo A

9

Güncelleme: Hata düzeltildi.

Teresa'nın cevabı sorunu çözmek için yeterli ve iyi.

Ek olarak, kesinlikle kırılmış bir davranış olduğu için hata raporu verdim .

— int_ua
kaynak

Neden reddedildiğini bilmiyorum ama bu bana da bir çekirdek böceği gibi geliyor. Bugün büyük bir üniversite sunucusunu çökertip haftalarca süren bazı işlemleri öldürdüm ... Bu hata raporunu doldurduğun için teşekkürler!

— shapecatcher

7

OOM, 2014’te, 2018’de (ve 18.04’te) düzeltilmiş olabilir, OOM katili yine bir şey yapmıyor.

— skerit

0

Kullanıcı alanında çalışan ve OOM durumunda en büyük süreci öldürmeye çalışan bir OOM katili olan Earlyoom'u deneyebilirsiniz .

— qwr
kaynak

-1

Her şeyden önce 13.10 güncellemesini öneririm (temiz kurulum, verilerinizi kaydedin).

Güncellemek istemiyorsanız vm.swappiness öğesini 10 olarak değiştirin ve ram'ınızla ilgili bir sorunla karşılaşırsanız zRAM yükleyin.

— Brask
kaynak

2

Sizi düşüren kişi ben değildim, ancak genel olarak düşürmek vm.swappiness, düşük bellek sorunlarından muzdarip sistemlerde daha da fazla etkiye neden oluyor.

— Teresa e Junior

Önce tokmağı sıkıştırdığınızda ve daha sonra çok daha yavaş olan ve bilgisayarınızın donmasına neden olabilecek disk kullanımından kaçının.

— Brask

Teoride, zRAM hoş bir şeydir, ancak CPU açtır ve genellikle maliyeti yoktur. Bellek genellikle elektrikten çok daha ucuzdur. Ayrıca, RAM yükseltmenin daha pahalı olduğu bir dizüstü bilgisayarda, CPU kullanımı çoğunlukla istenmez.

— Teresa e Junior

İstediği şey, daha istikrarlı bir sisteme sahip olmaktır zRAM ve değişen değiş tokuş sistemi, daha fazla CPU kaynağı kullanmasına neden olacaktır, ancak atm sınırlı ve hataları olan bellek, sorunu çözmek istiyor, teori dersi değil, sorunu çözmek istiyor. zRAM yüklediğinizde ne olacağı.

— Brask

Sorusundan, gereğinden fazla yiyen uygunsuz bir senaryo yazabileceği açıktır (ve ben bunu zaten kendim yaptım). Böyle bir durumda, birkaç saniye içinde komut dosyasını kapmak için gigabayt RAM'i birkaç saniyede izleyebilir ve zRAM kurtarmaya gelmez, çünkü senaryo yeterince tatmin edilmeyecektir.

— Teresa e Junior