OOM katili düzgün çalışmıyor, donmuş bir işletim sistemine neden oluyor

Yıllarca, işletim sistemimin OOM katili düzgün çalışmıyor ve donmuş bir sisteme yol açıyor.
Bellek kullanımı çok yüksek olduğunda, tüm sistem belleği boşaltmak için işlemleri öldürmek yerine saatlerce , hatta günlerce "donma" (aslında: aşırı yavaşlama) eğilimindedir . Kaydettiğim maksimum süre, sıfırlama işlemini yapmak için kendimi istifa etmeden 7 gün önce. OOM'a ulaşmak üzereyken , iyot ölçülemez hale gelmeden önce çok yüksektir (~% 70). Araç: Her programın sabit diskimden çok yüksek bir verimle (onlarca MB / sn) okuduğunu gösterdi. Bu programlar ne okuyor?


iotop

- Dizin hiyerarşisi?
- Çalıştırılabilir kodun kendisi mi?
Ben tam olarak şimdi değilim.

[değiştirildi] Bu mesajı yazdığımda (2017'de) güncel bir ArchLinux kullanıyordum (4.9.27-1-lts), ancak sorunu daha önce yıllarca yaşadım.
Aynı sorunu çeşitli Linux dağıtımları ve farklı donanım yapılandırmaları ile de yaşadım.
Şu anda (2019), güncel bir Debian 9.6 kullanıyorum (4.9.0) İşletim sistemimin yüklü olduğu bir SSD olan 16 GB fiziksel ram, herhangi bir takas bölümü yok.

Sahip olduğum koç miktarı nedeniyle, bir takas bölümünü etkinleştirmek istemiyorum çünkü konunun ortaya çıkmasını geciktirecektir.
Ayrıca, SSD'lerin çok sık değişmesi, diskin ömrünü azaltabilir.
Bu arada, zaten bir takas bölümüyle ve bu bölüm olmadan denedim, yalnızca sorunun ortaya çıkışını geciktirdiğini, ancak çözüm olmadığını kanıtladı.

Bana göre sorun, Linux'un temel verileri donmuş bir sisteme götüren önbelleklerden ayırmasıdır , çünkü her seferinde sabit sürücüden her şeyi okumak zorundadır.

Linux'un çalışan programların çalıştırılabilir kod sayfalarını bırakıp bırakmayacağını bile merak ediyorum, bu da normalde bu kadar çok veri okumayan programların neden bu şekilde davrandığını açıklıyor.

Bu sorunu çözme umuduyla birkaç şey denedim.
Bir ayarlamak /proc/sys/vm/min_free_kbytesiçin 1000000(1 GB) oldu.
Bu 1 GB boş kalması gerektiğinden, bu hafızanın Linux tarafından önemli verileri önbelleğe almak için ayrılacağını düşündüm.
Ama işe yaramadı.

Ayrıca, ben, tanımlayarak bu fiziksel bellek büyüklüğüne sanal bellek boyutunu kısıtlamak, teoride büyük ses olabilir bile eklemek için yararlı düşünüyorum /proc/sys/vm/overcommit_memoryiçin 2, benim durumda terbiyeli teknik olarak mümkün olmadığı uygulamalar tür çünkü Kullandığım, bazı nedenlerden dolayı etkili bir şekilde kullandıklarından daha fazla sanal bellek gerektiriyor.
Dosyaya göre /proc/meminfo, Commited_ASdeğer genellikle sistemimdeki fiziksel ram değerinin iki katından daha yüksektir (16 GB, Commited_AS genellikle> 32 GB).

Bu sorunu /proc/sys/vm/overcommit_memoryvarsayılan değerine göre yaşadım : 0ve bir süredir bunu tanımladım: 1çünkü yanlış davranmak yerine OOM katili tarafından öldürülecek programları tercih ettim çünkü mallocne zamanların dönüş değerlerini kontrol etmiyorlar? tahsisler reddedilir.

IRC'de bu konuda konuştuğumda , aynı sorunu yaşayan diğer Linux kullanıcılarıyla tanıştım, sanırım birçok kullanıcı bununla ilgileniyor.
Bana göre bu kabul edilemez, çünkü Windows bile yüksek bellek kullanımıyla daha iyi başa çıkıyor.

Daha fazla bilgiye ihtiyacınız varsa, bir öneriniz varsa, lütfen bana bildirin.

Belgeler:
https://en.wikipedia.org/wiki/Thrashing_%28computer_science%29
https://en.wikipedia.org/wiki/Memory_overcommitment
https://www.kernel.org/doc/Documentation/sysctl/vm. txt
https://www.kernel.org/doc/Documentation/vm/overcommit-accounting
https://lwn.net/Articles/317814/

Bunun hakkında konuşuyorlar:
Neden Linux dışı bellek (OOM) katili otomatik olarak çalışmıyor, ancak sysrq-key'de çalışıyor?
OOM-katil neden bazen kaynak domuzlarını öldürmekte başarısız oluyor?
OOM Katilinin
Önyüklenmesi Zorla değişim sırasında OOM-katilini tetiklemek mümkün mü?
OOM durumuna yakın gecikmeyi nasıl önleyebilirim?
https://lwn.net/Articles/104179/
https://bbs.archlinux.org/viewtopic.php?id=233843

Ben neden olarak (aynı şeyin) iki açıklamaları buldum kswapd0 gelmez sabit diski okuma olur OOM katil kusurlu sürecini öldürür çok önce:

1. bu askubuntu SE cevabının cevabını ve yorumlarını görün
2. cevabı ve David Schwartz'ın unix SE hakkındaki bu cevabı üzerine yorumları görün

Burada, her şey dondurulmuşken neden sürekli disk okumaya başladığımdan beri gözlerimi gerçekten açmış olan yorumdan alıntı yapacağım :

Örneğin, sıfır takas ettiğiniz ve sistemin neredeyse RAM tükenmekte olduğu bir durumu düşünün. Çekirdek örneğin Firefox'tan hafıza alacaktır (bunu yapabilir çünkü Firefox diskten yüklenmiş çalıştırılabilir kod çalıştırıyordur - kod gerekirse diskten yüklenebilir). Eğer Firefox’un N saniye sonra bu RAM’e tekrar erişmesi gerekiyorsa, CPU’nun Linux’u bir miktar RAM’i boşaltması için zorlayan (örneğin başka bir işlemden bir miktar RAM’i alan) CPU’nun “sert hata” üretmesi durumunda, eksik verileri diskten yükleyin ve ardından Firefox’un olağan. Bu normal takas işlemine oldukça benzer ve kswapd0 yapar. - Mikko Rantalainen 15 Şubat, 13:08

Herhangi birinin bu davranışı nasıl devre dışı bırakacağına dair bir yolu varsa ( çekirdeği hangi seçeneklerle yeniden derlersiniz? ), Lütfen en kısa zamanda bana bildirin! Çok takdir, teşekkürler!

GÜNCELLEME: Ben şimdiye kadar bulduk tek yolu çekirdeği yama yoluyla olduğunu ve devre dışı takas ile benim için çalışıyor (yani. CONFIG_SWAP is not setAma takas etkinleştirilmiş olan başkaları için iş yapmaz) görünmektedir ; Bu sorunun içindeki yamayı görün .

memory.minParametre cgroups-v2bellek kontrolörü yardımcı olmalıdır.

Yani, alıntı yapmama izin ver:

Sabit hafıza koruması. Bir grubun hafıza kullanımı etkin sınır sınırı dahilindeyse, grubun hafızası hiçbir koşulda geri kazanılmaz. Korunmasız geri alınabilir hafıza mevcut değilse, OOM katili çağrılır.

Kaynak: https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html