Každodenní spotřeba RAM a pád serveru. [vyřešeno]

[Fenix]

Ahoj,
pomůžete mi prosím někdo s diagnostikou a odhalením příčiny zatuhnutí serveru? Ve virtuálním počítači (hypervisor je ProxMox) provozuji server na "Ubuntu 20.04.4 LTS", tento stroj má 8GB RAM a přidělené 4 jádra CPU a téměř každý večer server zatuhne, hypervisor ukazuje vyčerpání RAM a na konzoli jde vidět "havarovaný" Linux. Běžná spotřeba RAM serveru se motá kolem 2GB, na serveru je aktivovaný SWAP soubor o velikosti 16GB. Zajímavé je, že přes den server padne jen výjimečně, téměř nikdy, zato noc, ty on nemá rád...

Poradí mi porosím někdo, kde začít hledat?

[Ventero]

V Cronu? Co logy - nic?

[juwa2]

Hledej v souboru

Kód: [Vybrat]

/var/log/syslog
Orientuj se dle času kdy to "vytuhne".
Ještě bych zkontroloval disk a ramky (memtest).

[Fenix]

V Cronu? Co logy - nic?

V Cronu jsem nic závadného nenašel, pro jistotu jsem tam zakázal všechny úlohy a stejně server vytuhl...

V syslogu krom podivné hlášky:

Kód: [Vybrat]

^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
Po/před zatuhnutím nic není (dosolova, žádný text).

Pak už v systému vidím jen můj restart virtuálu...

[Fenix]

Hledej v souboru

Kód: [Vybrat]

/var/log/syslog
Orientuj se dle času kdy to "vytuhne".
Ještě bych zkontroloval disk a ramky (memtest).

Disky testnout bude trochu oříšek (jsou dva v ZFS RAID1), ale mohl bych ty virtuály dočasně přesunout na jiný disk a počkat, zda to zase zatuhne...
RAMku testnu a dám vědět, ale bude mi to asi pár dní trvat, než ten test udělám...

[Fenix]

Tak virtuál se zasekne i když má disky přesunutý na jiný fyzický disk..

[Fenix]

Tak jsem vzal disky a přenesl jsem je na jiný server a tam se VM také zasekávají...

Opět VM spotřebuje všechnu svou RAM a 1 jádro CPU běží na 100%.  Nějaký nápad?

[Ventero]

Zjistit, co bezi za procesy v tom virtualu?

[Petr Merlin Vaněček]

Bude to nějaký memleak, chce to v rámci toho virtuálu mrknout, který proces to dělá. Klidně bych mrsknul do crona co minutu výpis  - omezit to klině jen na tu noc (a v /root založit složku memory)

Kód: [Vybrat]

ps -o pid,user,%mem,command ax | sort -b -k3 -r >>$HOME/memory/`date +%d-%m-%H-%M`.log
Bude tam vidět, co začně vyžírat pamět

[Fenix]

Logování jsem nastavil. Ale začínám podezírat samotný hypervisor (Proxmox). Na internetu jsem viděl podobné stížnosti lidí a společný jmenovatel je nové jádro hypevisoru.

Prý jsou aktuálně dvě řešení:
1. Vrátit se na starší verzi jádra (Nevím na kterou...).
2. Na všech virtuálech snížit počet jader CPU na 1 + Enable NUMA.

Tak jsem vyzkoušel řešení č. 2 a zatím mám uptime systémů 26 hodin. Tak uvidím, zda to vydrží, nebo to je jen náhoda... Ale moc se mi trvale provozovat VM jen s jedním jádrem CPU nechce...

[Fenix]

Tak nyní je UpTime všech VM 70 hodin a zatím je vše v pořádku, problém je, že u jednoho VM mi vadí mít přidělené jen jedno jádro CPU.

Nechám běžet vše tak jak je týden a pokud bude vše v pořádku, zvýším u jednoho VM CPU na 2 jádra a dám vědět, zda server bude stabilní. A pak nezbývá než čekat na opravu v jádře... :-(

[Ventero]

Ano - jedině takhle postupně. Děkujeme

[juwa2]

Na opravu v jádře čekat nemusíš (a taky by ses nemusel dočkat). Můžeš vyzkoušet jakékoli z mainline (starší/novější).
https://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D
A které konkrétně? To musíš vyzkoušet, zkrátka nějaké zkus (můžeš jich mít nainstalovaných více současně). Na obrázku je jako příklad kernel 5.2. Ty můžeš ovšem zkusit jakýkoli jiný, začal bych třeba 5.14.21
Pozn: image-unsigned nelze nainstalovat se zapnutým secure-boot

[Fenix]

Bude to nějaký memleak, chce to v rámci toho virtuálu mrknout, který proces to dělá. Klidně bych mrsknul do crona co minutu výpis  - omezit to klině jen na tu noc (a v /root založit složku memory)

Kód: [Vybrat]

ps -o pid,user,%mem,command ax | sort -b -k3 -r >>$HOME/memory/`date +%d-%m-%H-%M`.log
Bude tam vidět, co začně vyžírat pamět

Tak po pěti dnech došlo opět k zatuhnutí serveru, log tvrdí, že k vyčerpání RAM nedošlo, ani ke zvýšené její spotřeby, takže GUI hypervisoru to ukazuje asi chybně...

[Fenix]

Tak jsem zjistil, že to že server zatuhne není chyba, ale že je to celkem logické a v pořádku

Ještě nechám systém pár dní běžet a pokud bude vše v pořádku, tak mé řešení zde popíšu a označím jako vyřešené...

[Petr Merlin Vaněček]

Tak jsem zjistil, že to že server zatuhne není chyba, ale že je to celkem logické a v pořádku

Ještě nechám systém pár dní běžet a pokud bude vše v pořádku, tak mé řešení zde popíšu a označím jako vyřešené...

Tak to jsem opravdu zvědav! :-)

[Fenix]

Tento komentář píši po 17 dnech bezproblémového provozu dotčených VM serverů.

Co popsaný problém způsobuje:
1. Diskové pole je na hypervisoru Proxmox provozováno pomocí souborového systému ZFS v konfiguraci 2 disků v zrcadle.

A to je první problém, ve výchozím stavu si tento souborový systém automaticky sebere půlku fyzické paměti počítače a je mu jedno, zda je to 1GB, nebo 2000GB.

Co s tím? Je potřeba se dívat na reálnou spotřebu RAM počítače a v tomto případě htop, který běžně používám lže a automaticky do volné paměti zahrnuje i RAM které je ve skutečnosti používaná jako ZFS cache.

Jak reálnou spotřebu RAM tedy zobrazím? Tímto příkazem:

Kód: [Vybrat]

free -h
Omezil jsem tedy v mém případě konzumaci RAM pro potřeby ZFS cache na max 1,5GB:

Kód: [Vybrat]

echo 'options zfs zfs_arc_max="2684354560"' >> /etc/modprobe.d/zfs.conf
a min. na 1GB:

Kód: [Vybrat]

echo 'options zfs zfs_arc_min="1073741824"' >> /etc/modprobe.d/zfs.conf
Následně je potřeba aktualizovat nastavení zavaděče:

Kód: [Vybrat]

update-initramfs -u
A pokud jako já používáte EFI, tak ještě:

Kód: [Vybrat]

pve-efiboot-tool refresh
Pak je potřeba hypervisor restartovat.

Níže uvedený příkaz ukáže statistiky ARC cache pro ZFS:

Kód: [Vybrat]

arc_summary
A aktuální použití RAM ARC zjistíte pomocí:

Kód: [Vybrat]

arcstat
2. Druhou částí problému je to, že proces, který se stará o řešení (zabíjení) procesů o kterých si myslí, že se vymknul kontrole, nefunguje dostatečně agresivně, a i když má srv. k dispozici povolený několika GB SWAP (v mém případě 32GB), rozhodne se raději proces zmrazit a SWAP nepoužít. Ono zmrazení procesu je to, co mi způsobovalo zamrzání virtuálů na daném hypervisoru.

Pomocí příkazu:

Kód: [Vybrat]

echo 3 > /proc/sys/vm/drop_caches
Lze "manuálně", např. pomocí crone donutit systém, aby po sobě uklízel cache ZFS, protože samotnému procesu se do toho moc nechce.

Tímto způsobem lze systém nakonec u stabilizovat, ale popravě, já jsem se na to nakonec vykašlal. Nainstaloval jsem na daný server jiný hypervisor, konkrétně VMware ESXi který je pro mé účely zdarma a od té doby nemusím nic řešit, vše je naprosto stabilní a nemám ani v náznaku problém s RAMkou i když využívám více jádrové VM.

Jednotlivé VM jsem znovu neinstaloval, pouze jsem jejich disky zkonvertoval do formátu VMware a překopíroval je přes externí USB disk do nového umístění...

Tzn., problém nebyl ve VM který vždy v noci zamrzl, ale byl v hostitelském OS, tedy v hypervisoru.

[Petr Merlin Vaněček]

Díky za informace a označuji za vyřešené.