Řešení 1:
Přetížení paměti lze zakázat pomocí vm.overcommit_memory=2
0 je výchozí režim, kde jádro heuristicky určuje alokaci výpočtem volné paměti v porovnání s požadavkem na alokaci. A nastavením na 1 aktivujete režim wizardry, kde jádro vždy hlásí, že má dostatek volné paměti pro jakoukoli alokaci. Nastavení na 2 znamená, že procesy mohou přidělovat pouze konfigurovatelné množství (overcommit_ratio ) RAM a začnou dostávat zprávy o selhání alokace nebo OOM, když překročí toto množství.
Je to bezpečné, ne. Neviděl jsem žádný správný případ použití, kdy by deaktivace přetížení paměti skutečně pomohla, pokud si nejste 100% jisti pracovní zátěží a kapacitou hardwaru. V případě zájmu si nainstalujte kernel-docs balíček a přejděte na /Documentation/sysctl/vm.txt přečíst si více, nebo si to přečíst online.
Pokud nastavíte vm.overcommit_memory=2 pak dojde k přetížení až do procenta fyzické paměti RAM nakonfigurované v vm.overcommit_ratio (výchozí hodnota je 50 %).
echo 0/1/2 > /proc/sys/vm/overcommit_memory
To nepřežije restart. Pro zachování platnosti to vložte do /etc/sysctl.conf soubor:
vm.overcommit_memory=X
a spusťte sysctl -p . Není třeba restartovat.
Řešení 2:
Naprosto nekvalifikované prohlášení:Zakázání přetížení paměti je rozhodně „bezpečnější“ než jeho povolení.
$customer to má nastaveno na několika stovkách webových serverů a hodně to pomohlo s problémy se stabilitou. Existuje dokonce i kontrola Nagios, která skutečně hlasitě volá oheň, pokud to někdy NENÍ deaktivováno.
Na druhou stranu, lidé nemusí považovat za „bezpečné“ vyřazování jejich procesů z paměti, když by chtěli jen přetížit malou ram a nikdy by to skutečně nepoužili. (tj. SAP by byl velmi dobrým příkladem)
Takže jste zpět k tomu, abyste zjistili, zda to pro vás zlepšuje věci. Vzhledem k tomu, že se tím již zabýváte, abyste se zbavili souvisejících problémů, myslím, že by vám to mohlo pomoci.
(Vím, že budu riskovat záporný hlas nějakého nevrlé osoby)
Řešení 3:
Souhlasím s tím, že deaktivace overcommit je za určitých okolností bezpečnější než povolení. Pokud server spouští pouze několik velkých paměťových úloh (jako jsou simulace obvodů v mém případě), je mnohem bezpečnější odepřít aplikaci požadavek na paměť předem, než čekat na událost OOM (která bude jistě brzy následovat) Poměrně často vidíme servery problémy poté, co OOM zabiják odvedl svou práci.