OOM-Killer neden çok fazla şey isteyen süreci öldüremiyor?

Burada OOM-Killer'in şu şekilde yapılandırılabileceği overcommit_memoryve aşağıdakilerin açıklandığı açıklanmaktadır :

2 = fazla taahhüt yok. Çok fazla sorulması halinde tahsisler başarısız olur.
0, 1 = aşırı taahhüt (sezgisel olarak veya her zaman). Çok fazla belleğe gerçekten erişildiğinde, bazı sezgisel tarama temelli bazı işlemleri öldürün .

Şimdi, bunu tamamen yanlış anlayabilirim, ama neden tahsis edilen çok fazla belleğe erişmeye çalışan süreci öldürmek için bir seçenek (veya neden varsayılan değil) yok?

linux out-of-memory

— Martin Ba
kaynak

Kritik bir sistem işlemi çok fazla bellek isterse ne olur?

— Lawrence

İlk olarak - bu şeyi yapabilir . Ama, bu soruyla en büyük sorun büyük ihtimalle bir süreç ise yani soran bellek için o zaman ediliyor yeni veya başka bir deyişle, bu çok geçerli işleme katılan yeni bir süreç olduğunu - idam. OOM, 3 gün boyunca açılmayan im istemcinizin sistem belleğini boşa harcamasına izin vermeyi mi tercih edersiniz yoksa YouTube'un bu yıl biraz zaman yüklemesini mi tercih edersiniz? linuxatemyram.com

— mikeserv

Bu nedir no overcommitseçenek aslında yok. Bir işlem çok fazla bellek isterse başarısız olur. Hatayı kontrol ederse, genellikle kendini öldürür; eğer dönmezse, malloc()döndüren boş göstergenin atılmasını denediğinde muhtemelen bir Segmentasyon Hatası alır ve çökecektir .

— Barmar

no overcommitBelirtilen kaynaklara göre ( kernel.org/doc/Documentation/vm/overcommit-accounting gibi ) 2'nin aslında mod olduğunu unutmayın . Sanırım sorunuzu buna göre düzenleyeceğim.

— hans_meine

Şu senaryoyu inceleyin:

4 GB belleğiniz var.
Hatalı bir işlem 3.999GB ayırır.
Kaçak işlemini öldürmek için bir görev yöneticisi açtınız. Görev yöneticisi 0.002GB ayırır.

Öldürülen süreç, bellek isteyen son işlem olsaydı, görev yöneticiniz öldürülürdü.

Veya:

4 GB belleğiniz var.
Hatalı bir işlem 3.999GB ayırır.
Kaçak işlemini öldürmek için bir görev yöneticisi açtınız. X sunucusu görev yöneticisinin penceresini işlemek için 0,002 GB ayırır.

Şimdi X sunucunuz öldürüldü. Soruna neden olmadı; sadece "yanlış zamanda yanlış yerde" idi. Kalan kalmadığında daha fazla bellek ayıran ilk süreç oldu, ancak başlamak için tüm belleği kullanan süreç değildi.

— user253751
kaynak

Örneğinizi genişletmek, eğer bir işlem belleğinizin% 99.999'unu tüketiyorsa, onu asla öldüremezsiniz, çünkü onu öldürebilecek herhangi bir şey bellek gerektirir ve böylece hatalı süreç öldürülmeden önce kendini öldürür!

— Kızak

Dikkat edin, bu Linux felsefesi, gerekli bir gerçek değil. Windows 3.0, gerekli iletişim kutuları da dahil olmak üzere OOM işleme için ayrılmış yeterli belleğe sahip olmasıyla çözdü.

— MSalters

@ MSalters: Bu örnek için gerçekten geçerli değil; Örnek, neredeyse tüm belleği ayıran bir işlemle ilgilidir , yani. kendini öldürmek için yeterli değil. Açıkçası, herhangi bir işletim sisteminde OOM kullanımı için yeterli bellek olması gerekir. Ancak OOM işlemeyi başlatan süreç, yanlış davranan değil, bellek ayırmak için gerçekleşen bir sonraki süreç olacaktır. Tabii ki, Windows 3.0'ın her zaman görev yöneticisini çalıştırmak için yeterli belleğe sahip olduğunu veya OOM işleyicisinin her zaman kullanıcıdan işlemi öldürmesini istediği anlamına gelmez. (Hangi! = Suç işleme sürecini öldürüyor)

— Aleksi Torhamo

@AleksiTorhamo: Gerçekten ikincisini kastetmiştim. Windows 3.0 tam dolu bir görev yöneticisine sahip değildi, hafızası önceden belirlenmiş olan ünlü mavi ekranlara sahipti.

— MSalters