Vyhněte se rušení linuxové aplikace kvůli nedostatku paměti

Řešení 1:

Ve výchozím nastavení má Linux poněkud poškozený koncept správy paměti:umožňuje vám alokovat více paměti, než má váš systém, a pak náhodně ukončí proces, když se dostane do potíží. (Skutečná sémantika toho, co je zabito, je složitější – vyhledejte si „Linux OOM Killer“ pro spoustu podrobností a argumentů o tom, zda je to dobrá nebo špatná věc).

Chcete-li do správy paměti vrátit trochu zdravého rozumu:

1. Zakažte OOM Killer (zadejte vm.oom-kill = 0 v /etc/sysctl.conf)
2. Zakažte přetížení paměti (zadejte vm.overcommit_memory = 2 v /etc/sysctl.conf)
   Všimněte si, že se jedná o trinární hodnotu:0 ="odhadněte, zda máme dostatek paměti RAM", 1 ="Vždy řekněte ano", 2 ="řekněte ne, pokud nemáme paměť")

Tato nastavení způsobí, že se Linux bude chovat tradičním způsobem (pokud proces požaduje více paměti, než je k dispozici, malloc() selže a očekává se, že proces požadující paměť si s tímto selháním poradí).

Restartujte počítač, aby se znovu načetl /etc/sysctl.conf nebo použijte proc souborový systém pro okamžité povolení, bez restartu:

echo 2 > /proc/sys/vm/overcommit_memory 

Řešení 2:

Overcommit můžete zakázat, viz http://www.mjmwired.net/kernel/Documentation/sysctl/vm.txt#514

Řešení 3:

Krátká odpověď pro server je koupit a nainstalovat více paměti RAM.

Server, který běžně dostatečně zažívá OOM (Out-Of-Memory) chyby, pak kromě možnosti overcommit sysctl správce VM (virtuální paměti) v linuxových jádrech to není dobrá věc.

Zvýšení množství swapu (virtuální paměti, která byla odstráněna na disk správcem paměti jádra) pomůže, pokud jsou aktuální hodnoty nízké a využití zahrnuje mnoho úkolů, z nichž každá taková velká množství paměti, spíše než jednu nebo několik zpracuje každý požadující obrovské množství celkové dostupné virtuální paměti (RAM + swap).

Pro mnoho aplikací alokace více než dvojnásobného (2x) množství paměti RAM jako swap poskytuje klesající návratnost zlepšení. V některých velkých výpočetních simulacích to může být přijatelné, pokud je zpomalení rychlosti únosné.

S RAM (ECC nebo ne) být docela cenově dostupné pro skromné ​​množství, např. 4-16 GB, musím se přiznat, sám jsem tento problém už dlouho nezažil.

Základy pohledu na spotřebu paměti včetně použití free a top , seřazené podle využití paměti, jako dvě nejběžnější rychlá vyhodnocení vzorců využití paměti. Ujistěte se tedy, že rozumíte alespoň významu každého pole ve výstupu těchto příkazů.

Vzhledem k tomu, že neexistují žádná specifika aplikací (např. databáze, server síťových služeb, zpracování videa v reálném čase) a využití serveru (málo zkušených uživatelů, 100–1000 s připojení uživatele/klient), nemohu myslet na žádná obecná doporučení ohledně řešení problém OOM.

Řešení 4:

Pomocí ulimit můžete snížit množství paměti, kterou si může proces nárokovat, než bude zabit. Je to velmi užitečné, pokud je vaším problémem jeden nebo několik běžících procesů, které zhroutí váš server.

Pokud je váš problém v tom, že jednoduše nemáte dostatek paměti ke spuštění služeb, které potřebujete, existují pouze tři řešení:

1. Snižte paměť využívanou vašimi službami omezením mezipaměti a podobně

2. Vytvořte větší swapovací plochu. Bude vás to stát výkon, ale může vám to koupit nějaký čas.

3. Koupit více paměti

Řešení 5:

Zvýšení množství fyzické paměti nemusí být účinnou reakcí za všech okolností.

Jedním ze způsobů, jak to zkontrolovat, je příkaz 'atop'. Zejména tyto dva řádky.

Toto je mimo server, když bylo v pořádku:

MEM | tot   23.7G | free   10.0G | cache   3.9G | buff  185.4M | slab  207.8M |
SWP | tot    5.7G | free    5.7G |              | vmcom  28.1G | vmlim  27.0G |

Když to běželo špatně (a než jsme upravili overcommit_memory z 50 na 90, viděli jsme chování, kdy vmcom běžel výrazně nad 50G, oom-killer vyhazoval procesy do vzduchu každých pár sekund a zátěž neustále radikálně poskakovala kvůli tomu, že podřízené procesy NFSd byly přepáleny. a neustále znovu vytvářeny.

Nedávno jsme duplikovali případy, kdy víceuživatelské linuxové terminálové servery masivně přetěžují přidělení virtuální paměti, ale ve skutečnosti je spotřebováno jen velmi málo požadovaných stránek.

I když se nedoporučuje postupovat přesně touto cestou, upravili jsme overcommit-Memory z výchozích 50 na 90, což zmírnilo některé problémy. Nakonec jsme museli přesunout všechny uživatele na jiný terminálový server a restartovat, abychom viděli všechny výhody.