Dotaz: Chcípe mi server

[Ogeen]

Ahoj všem,

mám tu jednu virtuální mašinu na VMware. Běží na ní Ubuntu 18.04.4.

root@cos-srvm-checkmk01:~# uname -a
Linux cos-srvm-checkmk01 4.15.0-96-generic #97-Ubuntu SMP Wed Apr 1 03:25:46 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Mašina nepravidelně jednou až dvakrát za den vytuhne.

Těsně před chcípnutím se v logu objeví tato hláška, ale není to pravidlem:

Apr 16 19:09:05 cos-srvm-checkmk01 systemd[1]: Starting Clean php session files...
Apr 16 19:09:06 cos-srvm-checkmk01 systemd[1]: Started Clean php session files.

Někde jsem našel, že by Server mohl vytéct z paměti (4 GB) a mohlo by pomoct přidat SWAP, kterej sem vůbec nepoužíval.

Po přidání swapu se situace ještě zhoršila. Před přidáním swapu se sice na Server nedalo přihlásit přes ssh ani přes konzoli server však stále odesílal data do centrálního monitorovacího serveru. Po přidání swapu server prostě chcípne a jeho grafy na centrálním monitorovacím serveru jsou prázdné.

Server sám slouží jako vzdálený monitorovací node pro check_mk.

Díky za nakopnutí správným směrem.

Odpovědi

[Michal]

Takove chovani je konzistentni s tim, ze server vytece z pameti "explozivnim zpusobem" (pri beznem provozu tam chodi 10 requestu/s a najednou jich prijde 10x tolik, nebo tam prijde nejaky request, ktery vsechno zpomali/lockne, nejaky agregacni cron task treba), pak pridani swapu uskodi. Bud tam trvale pripojen pres SSH a monitoruj co se deje. Zajisti, aby maximalni pocet instanci (treba limit prefork php v apache) * maximalni velikost instance < RAM

[Max]

Buď dojde ram, ale to většinou začne řešit oomkiller, nebo je problém s disky a server vytuhne na tom, že nedokáže udělat žádnou IO operaci. Takže např. ssh naslouchá, ale přihlásit se nejde. Jednou se mi stalo, že jsem měl 2x SATA disk v RAID1 a i přes SMART se tvářily oba disky ok. Nicméně jakmile se spustil sync pole, tak probíhal šíleně pomalu a služby šly do kytek a celý server také.
Zdar Max

[Michal]

Moje zkusenost je takova, ze v situaci, kdy oom killer kosti jednu instanci apache+php za druhou a apache hned v zapeti forkne novou se system chova zpusobem, ktery uvadi tazatel :)

IO problem bych zvazoval, kdyby to nebyl VM. Pozoroval by problemy i na jinych virtualech.

[alkoholik]

SMART obcas trosku lze. Pro disky v RAIDu se vyplati nastavit smartctl -l scterc na par sekund.

[alkoholik]

Kdyz uz mas centralni monitorovaci server, vyrob si i centralni logovaci. Masina je obcas schopna po siti zahlasit veci, ktere pak uz na vlastnim rebootnutem serveru nenajdes.

[Ogeen]

Díky všem za rady.

Poladil sem Apache i check_mk, tak uvidíme jestli to pomůže.

[Ogeen]

Ahoj všem,

tak server je bohužel opět na krovkách. :(

V syslogu je těsně před pádem zalogován jen nějaký binární bordel:

Apr 18 05:51:01 cos-srvm-checkmk01 CRON[32495]: (firma_h) CMD (. $OMD_ROOT/etc/omd/site.conf ; curl http://localhost:$CONFIG_APACHE_TCP_PORT/firma_h/check_mk/run_cron.py >/dev/null 2>&1)
Apr 18 05:51:59 cos-srvm-checkmk01 systemd-resolved[1138]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
Apr 18 05:51:59 cos-srvm-checkmk01 systemd-resolved[1138]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
Apr 18 05:51:59 cos-srvm-checkmk01 crontab[480]: (firma_h) LIST (firma_h)
Apr 18 05:52:01 cos-srvm-checkmk01 CRON[777]: (firma_h) CMD (. $OMD_ROOT/etc/omd/site.conf ; curl http://localhost:$CONFIG_APACHE_TCP_PORT/firma_h/check_mk/run_cron.py >/dev/null 2>&1)
Apr 18 05:52:01 cos-srvm-checkmk01 CRON[778]: (firma_h) CMD ([ ! -e /omd/sites/firma_h/etc/check_mk/conf.d/microcore.mk -a -d /omd/sites/firma_h/var/check_mk/notify/bulk ] && cmk --notify send-bulks)
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@

[Aleš Kapica]

Zkontroluj si u té fyzické mašiny kde virtualizuješ, paměti. Vím. Za normálního běhu se to dělá blbě, ale hovoří ze mě reální zkušenost. Řešil jsem 2 roky podobný problém. Nakonec se ukázalo, že ze 4 paměťových modulů byly vadné dva a chyba se projevovala jen když byly moduly dva. Každý modul samostatně fungoval bez problému.

[Aleš Kapica]

Proč to trvalo dva roky jsem už tady zmínil před časem. Nejlepší by bylo, kdybys rovnou vyměnil ty paměťové moduly za otestované, a pak je na jiném stroji prověřil. Já tenkrát tuhle možnost neměl.

[jiwopene]

Jsou to samé NUL bajty. Je ten syslog z disku nebo odeslaný za běhu? Tohle bývá na některých FS tím, že se nestihl uložit na disk (fsync) soubor s logem.

[Ogeen]

Je to z disku.

[kapo]

Nejakej monitoring VM hosta, kterej by ukazal jakoukoliv anomalii VM pred jeho padem? Vysoke CPU, RAM, I/O, ... ?

[Josef Kufner]

Pokud se to začalo dít tak nějak samo od sebe, zkontroluj zda něco fyzicky neupadlo v tom serveru. Vibrace z ventilátorů, stárnoucí plasty a oxidující kontakty dokážou divy.

[Aleš Kapica]

To je pravda. Taky nám jednou takhle tuhnul stroj a ukázalo se, že se nějakým záhadným způsobem uvolnil vzadu ventilátor a jak se vyklopil, začal honit horký vzduch v bedně, místo aby ho táhl ven.

[Ogeen]

Díky za tip, ale je to virtuální mašina. Ostatní VM na stejném hostu jsou ok.

[Josef Kufner]

Pokud to je jediný náročný virtuální stroj, tak by to hardwarový problém mohl být. Pokud ostatní virtuální stroje jsou srovnatelné nebo náročnější, tak to bude nejspíš nedostatkem paměti či pomalém IO. Také by mohl být poškozený/unavený kus disku, kde tento stroj bydlí a to by mohlo způsobit pomalé IO zrovna jen v tomto případě.

[j]

Dost pochybuju, ze by chcipala jedna virtualni masina, a vmware, pripadne dalsi virtualy, by chodil vpohode, pokud by chyba byla v HW.

Spis zkus analyzovat kdy se to zaclo dit, a co se s danym strojem delalo predtim (nejaka zmena konfigurace, aktualizace ...). Pokud na nic neprijdes, tak proste vymen verzi toho phpcka za nejakou jinou, klidne i starsi. Podle toho co pises to neni ani verejny, takze nejaka bezpecnost te nemusi moc palit.

Jelikoz je to virtual, mas docela dobry moznosti se podivat, co se tam vlastne deje, da se principielne i tipnout obsah cely ramky. Otazka ovsem zni, zda nejaky obsahly zjistovani stoji za tu namahu.

Ad swap, to sebou nese v pripade virtualu jeste tu okolostoicnost, ze i kdyz vlastni stroj swap nema zadny, muze realne swapovat virtual. Pokud dojde na tu kombinaci, ze se cast ramky uz vlastne swapuje, a tak se pak jeste swapuje podruhy ... tak dochazi k nehezkym nechutnostem. Defakto jde o to, ze i kdyz si stroj mysli, ze ma X GB ram, muze mit ve skutecnosti X-N. To N je swap. A protoze algoritmy budou podobny, tak se realne stane, ze to N zacne swapovat znova, coz muze byt presne to, na co si narazil = zhorseni situace pridanim swapu.

Vmware v tomhle ohledu vcelku bezne umoznuje provozovat stroje s (i nasobne) vice ram, nez kolik je fyzicky dostupny. Predpoklada se, ze vetsina stroju pridelenou ramku nevyuzije nebo jen vyjimecne. A pokud chces, aby ta ramka byla opravdu pro danej virtual, musis mu ji vyhradit (v nastaveni virtualu).

Jinak receno, over si, co vsechno na tom vmware bezi, kolik to papka ramky, a kolik je realne dostupny. Dostupna RAMka je obecne na virtualech nejproblematictejsi zdroj. CPU ani diskovej prostor problem nebyva. Ve skutecnostit totiz trebas ty 4GB vubec nemas.

[V.]

Hmm, taky pravda.
Virtuál jde zpravidla zkopírovat jinam, na jiný hypervizor. Jdou dost často zvýšit fyzické zdroje.
Tak snad autor napíše, co najde.

[Oggen]

Díky za odpověď!

Host sám má jen 16GB RAM, přiděleno z ní je ca 9,5GB a Host hlásí, že využito je ca. 11,5GB. Na tom serveru se nic moc neděje.

V konfiguraci problémové mašiny jsem pro jistotu teď zaklikl "Reserve all guest memory (All locked)".

Swap jsmeza se odpojil.

Tak uvidíme jestli to bude mít na funkci nějaký vliv.

[Ogeen]

Tak server vydržel běžet přes noc, což se mu už nějakou dobu nepodařilo.

Tak uvidíme, jestli mu to vydrží.

[j]

Pokud jediny co si stim proved je ta zmena nastaveni ramky, a bude to fungovat, tak si zarid pridani ramky jak fyzickymu stroji tak tomu virtualu. Znamenalo by to, ze se tak jako tak pohybujes na hrane.

Ony vsemozny sledovace jsou totiz potvory pekne zravy.

[Aleš Kapica]

Musel bych ten stroj vidět zblízka. Ale jak už jsem zmínil výše, viděl bych to na nějaký problém na straně fyzické RAM. A je pouze otázkou času, kdy do toho problémového místa RAM sáhne něco jiného.

[Ogeen]

Tak server právě úspěšně zdechl.

Měl sem na konzoli spuštěný htop a ve chvíli pádu zatížení nula, nula, nic.

Resp. cpu1: 15,85, cpu2: 0,7%, load: 0.13 0.19 0.18 a paměť 2,18G/3,85G.

[Josef Kufner]

Zkontroluj ten fyzický server, na kterém to běží. Podívej se, zda všechny kabely jsou v pořádku, že tam není kopec prachu, že všechny chladiče a karty i paměti pevně drží. Protáhni paměť memtestem, projeď disk blok po bloku (badblocks má read-only režim a nedestruktivní zapisovací režim). Zkus tam spustit něco hodně náročného, co ten hardware zatíží a prohřeje. I když zlobí ten virtuální, problém může být hlouběji a nemusí se konzistentně projevovat.

Pak zkontroluj ten virtuální server, že filesystém není nakopnutý, že všechny soubory obsahují smysluplné věci. Můžeš to porovnat se starší zálohou, pokud máš nějakou z doby, kdy to nezlobilo. Tím zjistíš, co se změnilo a co by mohl být zdroj problémů. Případné chyby v systémových souborech můžeš opravit prostou přeinstalací všech balíčků (kdy konfigurace zůstane a jen se znovu rozbalí binárky a knihovny).

Můžeš se také podívat do logů balíčkovacího systému, zda se něco neaktualizovalo v době, kdy začaly problémy.

[lertimir]

A co je ve virtualizátoru? virtualizátor je také na nule?

[Ogeen]

Díky všem za tipy a odpovědi.

Virtuální mašinu jsem dnes ráno přesunul na jiný virtualizátor. Tak uvidíme jestli to bude chcípat i tam.

[Aleš Kapica]

Jiný, nebo stejný fyzický stroj?

[Ogeen]

Jiný fyzický stroj.

[Aleš Kapica]

Ok. Tím jsi vyloučil vliv fyzického HW.

Pokud to pojede v pohodě, tak bych se zaměřil na paměti toho původního stroje. Teda, pokud už neputuje do šrotu.