9.6 Dokümandaki "Aşırı Taahhüt ve OOM" ifadesi, @dunxd'nin, özellikle fazla mesaiye izin vermenin tehlikeleri ile ilgili bir grafik olduğunu göstermektedir. Ancak, 80benim için de ilginç görünüyordu, bu yüzden birkaç test yaptım.
Bulduğum şey, overcommit_ratioTÜM süreçler için mevcut olan toplam RAM'i etkilediği. Kök işlemler normal kullanıcı işlemlerinden farklı şekilde ele alınmaz.
Oranı 100veya altına ayarlamak, geri dönüş değerlerinin malloc/sbrkgüvenilir olduğu klasik anlambilimi sağlamalıdır . Oranları daha düşük ayarlamak, 100önbellekleme ve benzeri işlemler gibi işlem dışı etkinlikler için daha fazla RAM ayırmanın bir yolu olabilir.
Yani, bilgisayarımda 24 GiB RAM, takas devre dışı bırakılmış, 9 GiB kullanımda, topgösterilen
Mem: 24683652k total, 9207532k used, 15476120k free, 19668k buffers
Swap: 0k total, 0k used, 0k free, 241804k cached
İşte bazı overcommit_ratioayarlar ve ram-tüketici programımın ne kadar RAM alabileceğini (her sayfaya dokunmak) - her durumda program bir kez mallocbaşarısızlıkla temiz bir şekilde çıktı .
50 ~680 MiB
60 ~2900 MiB
70 ~5200 MiB
100 ~12000 MiB
Aynı anda birden fazla kullanıcı çalıştırmak, bazıları root kullanıcısı olsa bile, birlikte harcadıkları toplam miktarı değiştirmedi. Son 3+ GiB ya da öylesini tüketememesi ilginç; freeçok burada gösterilenden altına düşmedi:
Mem: 24683652k total, 20968212k used, 3715440k free, 20828k buffers
Deneyler dağınıktı - tüm RAM kullanımdayken malloc kullanan herhangi bir şey çökme eğilimindedir, çünkü birçok programcı C'deki malloc başarısızlıklarını kontrol etme konusunda korkunç, bazı popüler koleksiyon kütüphaneleri bunu tamamen görmezden gelir ve C ++ ve diğer bazı diller bile daha da kötüsü.
Gördüğüm hayali RAM'in ilk uygulamalarının çoğu , genellikle çok çok daha küçük fork()olan exec()bazı destek programlarına ihtiyaç duydukları tek bir büyük sürecin -% 51 + kullanılabilir bellek diyelim - olması gereken çok özel bir durumla ilgiliydi. Yazma-yazma anlambilimine sahip işletim sistemleri izin verecek fork(), ancak şart koşulu ile eğer çatallı işlem gerçekten çok fazla bellek sayfasını değiştirmeye çalıştıysa (her biri ilk büyük işlemden bağımsız olarak yeni bir sayfa olarak başlatılmalıdır) öldürülmek zorunda kalacaktı. Ana süreç sadece daha fazla hafıza tahsis edildiğinde tehlikedeydi ve bazı durumlarda sadece başka bir işlemin ölmesini bekleyip sonra da devam ederek bitiyordu. Çocuk süreci genellikle kendini yeni (genellikle daha küçük) bir programla değiştirdi.exec() ve daha sonra şartsızdı.
Linux'un aşırı alım konsepti, hem fork()gerçekleşmesine hem de tek işlemlerin toplu olarak toplanmasına izin verilmesine izin veren aşırı bir yaklaşımdır . OOM katili kaynaklanan ölüm bile programlara, eş zamanlı gerçekleşmeyebilir yapmak sorumlu kolu bellek ayırmayı. Genel olarak sistem genelindeki aşırı görevden ve özellikle de oom katilden nefret ediyorum - bu, kütüphaneleri etkileyen ve onları kullanan her uygulama aracılığıyla hafıza yönetimine kötü niyetli bir bakım yaklaşımı teşvik ediyor.
Oranı 100 olarak ayarlamanızı ve takas bölümünün olmasını, genellikle yalnızca büyük süreçler tarafından kullanılmaya başlanmasını öneririm - bu genellikle takas alanlarının bir kısmının sadece küçük bir kısmını kullanır ve böylece Proseslerin büyük çoğunluğunu OOM öldürücü yanlış kullanımından korumak. Bu, web sunucunuzu rastgele ölümden korumalı ve mallocsorumlu bir şekilde ele almak için yazılmışsa , kendisini öldürmekten bile güvenli olmalı (ancak ikinciye bahis yapmayın).
Bu, içinde kullanıyorum anlamına gelir /etc/sysctl.d/10-no-overcommit.conf
vm.overcommit_memory = 2
vm.overcommit_ratio = 100