Řešení 1:
Právě jsem se podíval na výpis oom logu a pochybuji o přesnosti toho grafu. Všimněte si prvního řádku 'Node 0 DMA32'. Říká to free:3376kB , min:3448kB a low:4308kB . Kdykoli volná hodnota klesne pod nízkou hodnotu, kswapd by měl začít vyměňovat věci, dokud se tato hodnota opět nezvýší nad vysokou hodnotu. Kdykoli volné klesne pod min, systém v podstatě zamrzne, dokud ho jádro nedostane zpět nad min. Tato zpráva také naznačuje, že swap byl zcela použit, kde je uvedeno Free swap = 0kB .
V zásadě se tedy spustil kswapd, ale swap byl plný, takže nemohl nic dělat a hodnota pages_free byla stále pod hodnotou pages_min, takže jedinou možností bylo začít zabíjet věci, dokud se nepodařilo obnovit pages_free.
Určitě vám došla paměť.
http://web.archive.org/web/20080419012851/http://people.redhat.com/dduval/kernel/min_free_kbytes.html má opravdu dobré vysvětlení, jak to funguje. Viz část 'Implementace' dole.
Řešení 2:
Zbavte se skriptu drop_caches. Kromě toho byste měli zveřejnit příslušné části vašeho dmesg a /var/log/messages výstup zobrazující zprávy OOM.
Chcete-li však toto chování zastavit, doporučuji vyzkoušet tento sysctl naladitelný. Toto je systém RHEL/CentOS 6 a zjevně běží na omezených zdrojích. Je to virtuální počítač?
Zkuste upravit /proc/sys/vm/nr_hugepages a zjistěte, zda problémy přetrvávají. Může se jednat o problém s fragmentací paměti, ale zjistěte, zda toto nastavení neovlivňuje. Chcete-li, aby byla změna trvalá, přidejte vm.nr_hugepages = value na váš /etc/sysctl.conf a spusťte sysctl -p znovu přečíst konfigurační soubor...
Viz také:Interpretace kryptických zpráv jádra „selhání alokace stránek“
Řešení 3:
V grafu nejsou k dispozici žádná data od začátku OOM zabijáka do jeho konce. Věřím, že v časovém rámci, kde je graf přerušen, ve skutečnosti spotřeba paměti prudce stoupne a již není k dispozici žádná paměť. Jinak by se OOM zabiják nepoužil. Pokud se podíváte na graf volné paměti poté, co se zabiják OOM zastavil, můžete vidět, že klesá z vyšší hodnoty než předtím. Alespoň odvedl svou práci správně a uvolnil paměť.
Všimněte si, že váš odkládací prostor je téměř plně využit až do restartu. To téměř nikdy není dobré a neklamné znamení, že zbývá málo volné paměti.
Důvodem, proč pro tento konkrétní časový rámec nejsou k dispozici žádná data, je to, že systém je příliš zaneprázdněn jinými věcmi. "Vtipné" hodnoty ve vašem seznamu procesů mohou být pouze výsledkem, nikoli příčinou. Není to neslýchané.
Podívejte se na /var/log/kern.log a /var/log/messages, jaké informace tam najdete?
Pokud se také zastavilo protokolování, zkuste jiné věci, vypisujte seznam procesů do souboru přibližně každou sekundu, stejně jako informace o výkonu systému. Spusťte jej s vysokou prioritou, aby mohl stále vykonávat svou práci (doufejme), když zatížení stoupne. I když pokud nemáte jádro s preemptem (někdy označované jako "serverové" jádro), můžete mít v tomto ohledu smůlu.
Myslím, že zjistíte, že příčinou je (jsou) procesy, které využívají nejvíce CPU% v době, kdy vaše problémy začínají. Nikdy jsem neviděl rsyslogd ani mysql chovat se tímto způsobem. Pravděpodobnějšími viníky jsou aplikace Java a aplikace řízené gui, jako je prohlížeč.