Dotaz: Centos 7 - Cannot allocate memory (zase...)

[vandrovnik]

Dobrý den,

na produkčním serveru s 64 GB RAM se nám zase v logu objevuje "Cannot allocate memory". Postiženy jsou různé procesy nahodile, první byl ClamAV, ale týká se to všech.

Paměti by mělo být dost:

# free
              total        used        free      shared  buff/cache   available
Mem:       65862960    10710596     8131608     2213480    47020756    52227244

Nejsou ale nejspíš volné žádné velké (4096 kB) bloky paměti:

# cat /proc/buddyinfo
Node 0, zone      DMA      0      0      1      0      2      1      1      0      1      1      3
Node 0, zone    DMA32     80     50     18      4     47     20     41     13     31      2     47
Node 0, zone   Normal    250    562    300   4756   6768   5074   2872   2119   1077   1803      0

Může to být příčinou problému?

Popř. nesetkal jste se s tím někdo a nenašel řešení? Večer zkusím restart, zkusím ještě vypnout KSM, ale bohužel netuším, co může být špatně.

Díky,

Karel

---

---

Odpovědi

[marsur]

a ako sa tvori vytazovanie procesov v zavislosti na hw? (nejaky top, htop)?

[drunkezz]

ulimits/hugepages?

D.

[vandrovnik]

# ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 257192
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 257192
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

vm]# cat nr_hugepages
0

[vandrovnik]

I když, asi se do toho pletou Transparent Huge Pages:

# grep Huge /proc/meminfo
AnonHugePages:   7374848 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB

[marsur]

dakujem :) chcel som napisat tvari a vznikol z toho taky srandovny preklep. :) kazdopadne dakujem, aspon viem nieco dalsie :)

[vandrovnik]

Běží tam nyní 6 virtuálních PC, ty nějaký výkon berou, ale většinou je 85-87 % iddle. Virtuálů je normálně 7, jeden jsem ukončil, tím jsem získal +- 230 volných těch největších paměťových bloků. Předtím např. freshclam psal, že nemá dostatek paměti, po ukončení virtuálu freshclam proběhne.

top - 15:54:11 up 5 days, 22:13,  1 user,  load average: 1.48, 1.28, 1.24
Tasks: 296 total,   1 running, 295 sleeping,   0 stopped,   0 zombie
%Cpu(s):  8.6 us,  4.4 sy,  0.0 ni, 86.5 id,  0.5 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem : 65862960 total, 50442508 free,  9600916 used,  5819536 buff/cache
KiB Swap:  8388604 total,  8388604 free,        0 used. 53237312 avail Mem

[xen]

Xen?

[vandrovnik]

Používáme kvm

[Josef Kufner]

Kolik má každý z virtuálů přiděleno paměti? Je to dohromady méně, než je v systému fyzické paměti?

[vandrovnik]

Každý má přidělen 1 GB, tj. celkem 7 GB (plus nějaká režie okolo), ale server má 64 GB RAM, takže by to neměl skoro poznat.

[ram]

Tedy já mám 32 GB RAM a čas od času se stane, že jde systém do swapu (který mám).

Možná by stálo za to si vyrobit nějaký odládací prostor - vytvořit soubor, naformátovat a připojit ho jako swap a zkusit, jak se to bude chovat.

Teď máš podle výpisu volných cca 8 GB, pustíš firefox s pár taby a je to pryč.

Sám nastavuji /proc/sys/vm/vfs_cache_pressure na vysoké hodnoty právě kvůli vracení cache stránek.

[mishkooo1]

Tebe by pomohlo zadat si do sysctl.conf pre perzistente nastavenie:

vm.swappiness = 10

a pre runtime zmenu (nemusis restartovat):

sysctl vm.swappiness=10

[vandrovnik]

Na vfs_cache_pressure (aktuálně 100) se podívám, díky; nenapadlo mě, že by linux tu cache neuvolnil sám od sebe a místo toho by aplikaci odmítl s tím, že nemá volnou paměť.

Jinak swap tam mám taky - 8 GB, využito 0 (vm.swapiness mám 5).

[Michal Kubeček]

Spíš než takhle střílet naslepo byste se měl zaměřit na to, kdo přesně tu hlášku vypsal a proč - ono by to klidně nemuselo znamenat, že selhala alokace paměti v aplikaci, ale třeba jen nějaký syscall vrátil ENOMEM.

[vandrovnik]

Bohužel ale nevím, jak se tomu víc přiblížit - hláška o tom, že se nepodařilo alokovat paměť, byla teď k vidění u ClamAV. Vypsal ji yum. Minule mariadb, httpd, firebird... Když jsem ukončil jeden z virtuálů a chtěl ho pak znovu spustit, také už to nešlo shláškou ohledně nedostatku paměti. Nicméně celou tu dobu se zobrazovalo free +- 53 GB.

[vandrovnik]

Těch 53 GB bylo v top jako "avail", nikoliv "free".

[Peter Golis]

Keď som ešte bol mladý a moja výplatná páska mi bola doručovaná na papieri, tak bežne používané OS mali možnosť defragmentovať RAM. Či už s pomocou natívnych nástrojov, alebo nástrojov tretej strany. Neviem čo sa porobilo že to niekto nezautomatizoval. Asi zlacnela RAM až na takú úroveň, že bežného smrteľníka nezruinuje keď si nakúpi všetku RAM čo dokáže napchať do počítača. Síce to nevyrieši problém, ale ho aspoň oddiali.

Niektoré zlé jazyky tvrdia že toto nefunguje:

sysctl vm.compact_memory=1  

a zhodí to počítač. Akurát nezaručujem že to funguje aj na virtuálky čo majú alokovanú pamäť s kadejakými nezmyselnými príznakmi.

[Michal Kubeček]

Neviem čo sa porobilo že to niekto nezautomatizoval.

Pokud se ptáte na to, proč se memory compaction neprovádí i když není potřeba (ani není explicitně vynucena uživatelem), odpověď je, že je to dost náročné na výkon, takže není žádoucí, aby se něco takového spouštělo samo od sebe a náhodně spotřebovávalo CPU.

[Peter Golis]

Nie, nepýtal som sa prečo sa to nerobí, aj keď to nie je treba. Pýtal som sa prečo to niekto nezautomatizoval.

Sú situácie kedy by sa to malo zapnúť. Napríklad keď si proces vyžiada súvislý blok pamäte, ale nedostane ho aj napriek tomu že má systém dosť voľnej pamäte.

[Michal Kubeček]

Napríklad keď si proces vyžiada súvislý blok pamäte, ale nedostane ho aj napriek tomu že má systém dosť voľnej pamäte.

Přesně tak to ale už nějaký pátek funguje.

[Peter Golis]

Takže to funguje, a zabraňuje vzniku situácie kvôli ktorej nastala táto otázka.

[Michal Kubeček]

My především, jaká situace konkrétně nastala, takže nemá smysl spekulovat, jestli to souvisí s memory compaction (na což jsem upozorňoval už včera).

[Michal Kubeček]

My především nevíme, jaká…

[Peter Golis]

To je pravda. Akosi zabudol povedať ako to má nakonfigurované, opísal len výsledné príznaky.

[vandrovnik]

Jestli pomůže nějaký kus konfigurace, rád ho dodám, ale v zásadě jsem nic moc neměnil od výchozího stavu Centos 7.

V sysctl.conf mám:

vm.dirty_writeback_centisecs = 2000
vm.dirty_expire_centisecs = 4500
vm.swappiness = 5
vm.dirty_bytes = 33554432
vm.dirty_background_bytes = 67108864
vm.overcommit_memory=2
vm.overcommit_ratio = 10
kernel.panic = 30
kernel.panic_on_oops = 1
kernel.printk = 3 4 1 3

overcommit tam je nejspíš zbytečně, používali jsme jej na starším serveru, který měl jen 8 GB RAM.

[Michal Kubeček]

Spíš by bylo dobré vědět, jestli je o té selhané alokaci něco v logu jádra, protože tam bývají dost podrobné informace, ze kterých si lze udělat obrázek, co se vlastně přesně stalo.

[Peter Golis]

To je nastavenie jadra. Ale čo aplikácie, ak majú nastavené pam.požiadavky? Napr. neodswapovať, alokovať veľa minimálnych blokov na systéme kde sa používajú hugepages. A nebolo by odveci nehať si jadro vypisovať debug informácie o alokovaní.

[overcommit]

No vida, už se dostáváme dál.

Swap: 8 GB
RAM: 64 GB
vm.overcommit_memory=2 (default = 0)
vm.overcommit_ratio = 10 (default = 50)
vm.dirty_bytes = 33554432 (default = 0)
vm.dirty_background_bytes = 67108864 (default = 0)

Memory Allocation Limit = Swap Space + RAM * (Overcommit Ratio / 100)
Memory Allocation Limit = 8 + 64 * (10/100)
Memory Allocation Limit = 14,4 GB

[vandrovnik]

Moc díky, to je téměř určitě ono - nastavení bylo převzato ze staršího serveru, ten měl 8 GB RAM + 8 GB swap, tak to problém nedělalo, ale tady je to evidentně nesmyslné. Já si to bohužel neuvědomil, "overcommit" jsem vzal jako "procenta nad", což je evidentně špatně. Ze sysctl.conf jsem to vyhodil, v /proc/sys/vm/... jsem vrátil výchozí hodnoty a hádám, že už problémy nebudou.

Ještě jednou děkuju!

[Michal Kubeček]

Jen bych dodal, že těch situací, kdy je opravdu potřeba fyzicky souvislá paměť, není tak moc, jak by se zdálo - a v userspace je jich ještě méně.

[Peter Golis]

Napríklad sa jedná o alokáciu pamäte pre virtuálny stroj ktorý si zapne užívateľ. A to je predmetom pôvodnej otázky.

[vandrovnik]

Původní problém ale byl, že si na nemožnost alokovat paměť stěžoval ClamAV, popř. pak freshclam, když jsem ho chtěl ručně spustit (ten myslím chtěl něco málo přes 8 MB).

Minule, když se problém vyskytnul, si stěžoval httpd, a ten chtěl přitom bloky třeba 40 kB.

[Peter Golis]

Niesom si istý, či v prípade hugepages existuje blok o veľkosti napríklad 40kB.

[Michal Kubeček]

1. To neexistuje ani bez nich, alokace od jádra stejně nebudou mít menší granularitu než je velikost stránky.

2. To, že se používají huge pages, neznamená, že celý systém pracuje jen s nimi a nelze získat nic menšího.

[Peter Golis]

Menšie bloky ako je prirodzená veľkosť na danej architektúre získaš. Na to ale by tie bloky zaberali menej ako je tá veľkosť stránky potrebuješ tie stránky reorganizovať. A to stojí výkon ako pri defragmentovaní pamäte.

[Michal Kubeček]

Těch 40 KB samozřejmě problém není, to jsem se jen přehlédl. Ale alokace od jádra budou mít vždycky granularitu danou velikostí stránky. Bloky menší než stránka jádro userspace procesu přidělovat nebude, to si musí userspace vyřešit ve vlastní režii (typicky na úrovni libc).