Fórum Root.cz

Hlavní témata => Server => Téma založeno: aaa 11. 01. 2019, 23:31:27

Název: Server is down
Přispěvatel: aaa 11. 01. 2019, 23:31:27
Ahoj, v poslednej dobe sa mi stava, ze server je z nicoho nic nedostupny. v logu (syslog a tiez kernel.log) nachadzam v case padu len tieto znaky:

^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@........

po vzdialenom restarte (server je v datacentre) vsetko bezi bez problemov. netusite, cim by to mohlo byt sposobene? v case padu neregistrujem ziadny zvyseny traffic, stale je to cca 20MBit/s (out+in)

je to ubuntu 16.04.5

dik za kazdy tip.ak by ste potrebovali niejake dalsie data na vysetrenie, kludne ich paste-nem.
Název: Re:Server is down
Přispěvatel: Jenda 11. 01. 2019, 23:49:37
Tyhle znaky jsou nuly (v binárním smyslu, viz man ascii, @ má kód 0x40, tedy jednu jedničku, a znak Ctrl, zobrazovaný často jako ^, právě tento bit invertuje), a vzniknou když se souborový systém s otevřenými soubory nečekaně odpojí - syslog vždycky dostane nějaký prostor (prázdný, resp. s nulami) a pak do něj zapisuje, a když se do nestihne korektně zavřít, tak tam ty nuly zůstanou.

A co s tím, no, good luck. Viděl bych to na HW problém (přehřívání, vyschlé kondenzátory), nebo ti někdo vytáhl napájení. Pokud to má management, mohlo by tam být něco vidět.
Název: Re:Server is down
Přispěvatel: aaa 12. 01. 2019, 08:01:50
povodne bezal server na mojom vlastnom zeleze a myslel som si, ze to je tym - nejaky tech. problem, server uz nebol najmladsi, tak som presiel do virtualu, zelezo neviem ake je, ale asi to nebude nejaky srot, je to visrtual v nemecku. mam tam u nich 2 servery, a ten 2. bezi bez problemov, je ale pravda, ze na tom 2. je mensi traffic, cca 1MBit/s.

a teraz babo rad:) - technicky problem, ktory sa vyskytuje na 2 uplne odlisnych strojoch - to je naozaj divne. blbe je, ze som hned guglil, ale zial google mi nevratil ani jednu odpoved, ked som tam paste-ol tie znaky. poradite mi, prosim, ako mu anglicky definovat moj problem? - resp. ako sa anglicky povie to, co som nasiel v logu.


dikes
Název: Re:Server is down
Přispěvatel: Vilith 12. 01. 2019, 08:23:07
Co takhle popsat co vse tam bezi za sluzby?
Jake porty jsou otevrene?
Provadeji se pravidelne aktualizace OS?
Je ko KVMko?

Co zkusit pouzit jine distro, nez Ubuntu? Sice mas LTS. ale furt je to Ubuntu (mas ho instalovane alespon v nejake rozumne minimalni konfiguraci s poslednimi aktualizacemi?)
Název: Re:Server is down
Přispěvatel: honzikk 12. 01. 2019, 08:42:13
Co takhle popsat co vse tam bezi za sluzby?
Jake porty jsou otevrene?
...
Co zkusit pouzit jine distro, nez Ubuntu? ...
Troufnu si tvrdit, ze tady je docela hodne lidi co podle vypisu sluzeb diagnostikuji prpblem tazatele. Otevrene porty opravdu pomuou proroze to bude mit hodne spolecneho.

A nakonec radit instalovat jine distro na server ktery bezi a potrebuje opravit je fakt nejlepsi. To je jak kdyby nekdo potreboval radu se skodovkou a nekdo poradil koupit ford. Fakt super rada.
Název: Re:Server is down
Přispěvatel: aaa 12. 01. 2019, 09:04:13
Co takhle popsat co vse tam bezi za sluzby?
Jake porty jsou otevrene?
Provadeji se pravidelne aktualizace OS?
Je ko KVMko?

Co zkusit pouzit jine distro, nez Ubuntu? Sice mas LTS. ale furt je to Ubuntu (mas ho instalovane alespon v nejake rozumne minimalni konfiguraci s poslednimi aktualizacemi?)

bezi tam LAMP v minimalnej verzii, je to pravidelne aktualizovane. mozno, ale naozaj len mozno by to mohlo suvisiet s tym, ze som tam cca pred 2-3 mesiacmi pridal vnStat(i) a MRTG na monitoring trafficu, ale je to naozaj len hypoteza, pretoze ten server bezal 2 roky bez problemov a v poslednej dobe som mal nekolko (jednotky) takych vypadkov.
Název: Re:Server is down
Přispěvatel: Jenda 12. 01. 2019, 10:55:10
Takže je to virtuál? To vypnutí je že se fakt vypne (a musíš ho ručně nahodit)? Také je možné, že to zatuhne (třeba vyleakuje paměť) a sejme to nějaký watchdog zvenku (to by administrace toho virtuálu mohla vidět) nebo zevnitř.
Název: Re:Server is down
Přispěvatel: Vilith 12. 01. 2019, 11:03:27
Co "chyba" v zalohovacim scriptu virtualky na strane providera?

Deje se tak v nejaky pravidelny cas?

Kdo je hoster?
Název: Re:Server is down
Přispěvatel: aaa 12. 01. 2019, 11:35:51
cca v case padu servera som v logu MRTG nasiel toto:

Kód: [Vybrat]
2019-01-11 19:52:46: ERROR: It looks as if you are running two copies of mrtg in parallel on
       the same config file. There is a lockfile (/var/lock/mrtg/_etc_mrtg.cfg_l) and it is
       is only 0 seconds old ... Check your crontab.
       (/etc/crontab and /var/spool/cron/root)
2019-01-11 19:55:01: ERROR: I guess another mrtg is running. A lockfile (/var/lock/mrtg/_etc_mrtg.cfg_l) aged
135 seconds is hanging around. If you are sure that no other mrtg
is running you can remove the lockfile
len neviem, ci je to pricina alebo nasledok. aktualne to je virtual (64GB RAM, E5-2630 v4, 1GBit net), ale stavalo sa to, aj ked to bezalo na bare metal. bez akejkolvek vrstvy, proste ubuntu priamo na zeleze. nedeje sa to pravidelne. teraz som komplet odstranil MRTG tak uvidim, ci to uz bude OK. v obovh pripadoch (zelezo/virtual) som server restartol cez webove rozhranie z hostingu a potom uz o frcalo dalej bez problemov. ziadny velky traffic, vytazenie 0 0 nic, proste to islo do kolien:(
Název: Re:Server is down
Přispěvatel: Vilith 12. 01. 2019, 11:50:15
Cim je to virtualizovano?
Název: Re:Server is down
Přispěvatel: aaa 12. 01. 2019, 11:52:20
este som v syslogu nasiel toto vytuhnutie apache. ial neviem posudit "zavaznost" a "vztah k padu servera"

Kód: [Vybrat]
Jan 11 19:47:08 x kernel: [374645.389398] INFO: task apache2:3980 blocked for more than 120 seconds.
Jan 11 19:47:08 x kernel: [374645.389885]       Not tainted 4.4.0-139-generic #165-Ubuntu
Jan 11 19:47:08 x kernel: [374645.389951] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan 11 19:47:08 x kernel: [374645.390085] apache2         D ffff880dea79fc68     0  3980  20759 0x00000000
Jan 11 19:47:08 x kernel: [374645.390093]  ffff880dea79fc68 2f2f2f2f2f2f2f2f ffff880efc585400 ffff880be3f1c600
Jan 11 19:47:08 x kernel: [374645.390097]  ffff880dea7a0000 ffff880ef76fafa4 ffff880be3f1c600 00000000ffffffff
Jan 11 19:47:08 x kernel: [374645.390100]  ffff880ef76fafa8 ffff880dea79fc80 ffffffff818535e5 ffff880ef76fafa0
Jan 11 19:47:08 x kernel: [374645.390134] Call Trace:
Jan 11 19:47:08 x kernel: [374645.390486]  [<ffffffff818535e5>] schedule+0x35/0x80
Jan 11 19:47:08 x kernel: [374645.390491]  [<ffffffff8185388e>] schedule_preempt_disabled+0xe/0x10
Jan 11 19:47:08 x kernel: [374645.390494]  [<ffffffff818554c9>] __mutex_lock_slowpath+0xb9/0x130
Jan 11 19:47:08 x kernel: [374645.390497]  [<ffffffff8185555f>] mutex_lock+0x1f/0x30
Jan 11 19:47:08 x kernel: [374645.390599]  [<ffffffff81226a43>] path_openat+0x3c3/0x1340

je to tam celkom 10x:

Kód: [Vybrat]
cat syslog.1  | grep blocked
Jan 11 19:47:08 x kernel: [374645.389398] INFO: task apache2:3980 blocked for more than 120 seconds.
Jan 11 19:47:08 x kernel: [374645.390697] INFO: task apache2:15689 blocked for more than 120 seconds.
Jan 11 19:47:08 x kernel: [374645.391024] INFO: task apache2:23825 blocked for more than 120 seconds.
Jan 11 19:47:08 x kernel: [374645.391286] INFO: task apache2:26399 blocked for more than 120 seconds.
Jan 11 19:47:08 x kernel: [374645.391601] INFO: task apache2:1888 blocked for more than 120 seconds.
Jan 11 19:47:08 x kernel: [374645.391887] INFO: task apache2:5405 blocked for more than 120 seconds.
Jan 11 19:47:08 x kernel: [374645.392191] INFO: task apache2:5889 blocked for more than 120 seconds.
Jan 11 19:47:08 x kernel: [374645.392538] INFO: task apache2:7002 blocked for more than 120 seconds.
Jan 11 19:47:08 x kernel: [374645.392918] INFO: task apache2:7328 blocked for more than 120 seconds.
Jan 11 19:47:08 x kernel: [374645.398934] INFO: task apache2:7447 blocked for more than 120 seconds.
Název: Re:Server is down
Přispěvatel: aaa 12. 01. 2019, 11:53:51
Cim je to virtualizovano?

neriesme teraz virtualizaciu, uz som 2x pisal, ze sa to dialo aj na BARE METAL este predtym ako som migroval na VPS.
Název: Re:Server is down
Přispěvatel: Vilith 12. 01. 2019, 11:57:27
Cim je to virtualizovano?

neriesme teraz virtualizaciu, uz som 2x pisal, ze sa to dialo aj na BARE METAL este predtym ako som migroval na VPS.

A migrace do VPS byla cista nova instalace nebo jen prenos z fyzickeho stroje do virtualu? Jen se ptam, zda sis to "prenesl", nebo se to chova stejne na ruznych instalacich
Název: Re:Server is down
Přispěvatel: aaa 12. 01. 2019, 12:06:40
bola to komplet cisla instalacia nanovo. kazdopadne som trochu pokrocil:

1) na 99% mozem vylucit MRTG.
2) na LAMP-e bezi moja aplikacia, ktora z PHP vola bash scripty, ktore vykonavaju rozne casovo dlhe ulohy. a v logu jednotlivych requestov vidim ze neiktore bezali dlhie ako 600s !. co je divne, lebo tie bash scripty vzdy zacinaju "timeout 60 some command atd..."

z toho vyplyva chyba medzi klavesnicou a stolickou, takze to pravdepodobne pada koli nejakej design/arch chybe u mna.

nova otazka by mohla byt: ako docielit to, aby ten bash script skoncil  (bez ohladu na to, ci skoncil uspesne/neuspesne) po napr. 60 sekundach? proste aby apache nemusel cakat tak dlho?





Název: Re:Server is down
Přispěvatel: Vilith 12. 01. 2019, 12:30:39
Z PHP volat shell na produkcnim serveru? To je sluzba pro anonymni uzivatele?

Co pripravit v PHP frontu do DB a cronem spoustet scripty co si zkontroluji frontu a pokud je neco noveho, tak se spusti...
Název: Re:Server is down
Přispěvatel: aaa 12. 01. 2019, 12:44:56
zial, fronta nie je mozna. v momente ked client zavola GET na apache tak caka, kym ten request neskonci a klient obdrzi v http response ocakavany vysledok, alebo chybovy kod. zial, processing byva niekedy radovo 10-tky sekund a zrejme to ten apache polozi.

nefunguje to tak (a nechcem aby to tak fungovalo), ze:
1) urobi GET/POST dotaz
2) periodicky sa bude dotazovat, ci "sa to uz upieklo"


co mi poradite, ako by to bolo mozne naimplementovat lepsie, aby  apache nepadal na kolena, ale aby to nutne fungovalo "on demand/ bez pronty na spracovanie" - proste tak ako doteraz.

jasne, mohol by som to skalovat na viac serverov, ale tieto "performance vykyvy" nie su az tak caste, aby sa mi to vyplatilo.


 
Název: Re:Server is down
Přispěvatel: JardaP . 12. 01. 2019, 14:48:43
A nakonec radit instalovat jine distro na server ktery bezi a potrebuje opravit je fakt nejlepsi. To je jak kdyby nekdo potreboval radu se skodovkou a nekdo poradil koupit ford. Fakt super rada.

Ano, je, Ubuntu patri mezi nejmene spolehliva distra, kde bugy pretrvavaji celou vecnost.
Název: Re:Server is down
Přispěvatel: JardaP . 12. 01. 2019, 14:49:20
bola to komplet cisla instalacia nanovo.

A jednalo se o tu stejnou verzi Ubuntu?
Název: Re:Server is down
Přispěvatel: aaa 12. 01. 2019, 16:12:18
bola to komplet cisla instalacia nanovo.

A jednalo se o tu stejnou verzi Ubuntu?
ano, 16.04.5 ale ako pisem hore, problem je s najvacsiuo pravdepodobnostou u mna, resp. v designe. zial netusim preco timeout 60 v bash scripte nezaruci, ze command neskonci po 60sekundach.
Název: Re:Server is down
Přispěvatel: Jenda 12. 01. 2019, 18:00:34
Ty záseky jsou zajímavé, zatím vždycky když jsem něco takového viděl, tak to bylo způsobeno čekáním na I/O (ať intenzivní zátěž disku, nebo síťový filesystém (NBD, NFS) který vytuhl). Zkus logovat "ps axu | grep D".
Název: Re:Server is down
Přispěvatel: aaa 12. 01. 2019, 18:20:28
Ty záseky jsou zajímavé, zatím vždycky když jsem něco takového viděl, tak to bylo způsobeno čekáním na I/O (ať intenzivní zátěž disku, nebo síťový filesystém (NBD, NFS) který vytuhl). Zkus logovat "ps axu | grep D".

moze to byt nieco s diskovym IO pretoze jednotlive "tasky/requesty" mi bezne trvaju cca od 1-10 sec. niekedy viac, ale teraz vidim v logu doby trvania pred padom od 200-800 sekund, co je masaker, proste sa tam na nieco cakalo az to zlozilo server na kolena. musim najst nejaky toolna monitoring zataze disku/io - nieco ako htop.
Název: Re:Server is down
Přispěvatel: ByCzech 13. 01. 2019, 03:15:39
iotop
Název: Re:Server is down
Přispěvatel: Jenda 13. 01. 2019, 07:24:23
Problém s iotopem je, že ukazuje průtok, ale minimálně na rotačních discích jsou mnohem zajímavější seeky (čtení náhodných bloků rychlostí 200 kB/s sejme výkon víc než sekvenční čtení 50 MB/s). A že se něco zaseklo úplně tam neuvidíš. Já někdy grepuju procesy v "D" stavu a něco z toho jde vykoukat.

Nicméně i to by mělo působit zátuh, nikoli vypnutí -- bohužel tazatel zatím neupřesnil jak se to vypnutí děje a jestli to může shodit nějaký watchdog.
Název: Re:Server is down
Přispěvatel: aaa 13. 01. 2019, 08:00:59
zdar,

aby som sa vratil k otazkam bez odpovedi:

1) bohužel tazatel zatím neupřesnil jak se to vypnutí děje
proste som sa prihlasil na admin rozhranie hostingu a restartol server, neriesil som, ci je to len zaseknute, alebo vypnute. neslo mi server pingnut ani som sa sa nemohol dostat na jeho web, tak som to restartol

2) ziadny watchdog tam na 100% nie je. hosting poskytuje size ochranu proti DDoS ale ziadny DDoS tam nebol, vsetko zrejme chyba designu.

3) poriesil som to tam, ze sa naimplementoval kontrolu na max pocet workerov/requestov per "client". client ale nie je browser, alebo webovy klient, ale kazdy moj uzivatel, ktory pri requeste pouzije jednoznacky identifikator a ked detekujem viac requestov s rovnakym identifikatorom ako je limit na uzivatela, tak vsetky nad limit vraciam s chybovou hlaskou. asi by sa dalo najst aj nieco elegantnejsie (tipom sa nebranim) ale ja potrebujem pokryt len narazove spicky. uvidime ako to zafunguje a hlavne ci som tento limit nastavil optimalne, tj. nie velmi nizky, aby uzivatelia neprskali, ale zase ani nie velmi vysoky, aby to opat nepadlo na kolena.

zdar
Název: Re:Server is down
Přispěvatel: aaa 13. 01. 2019, 08:06:33
este som zabudol

 bod 4) disk tam je SSD 1.6TB z toho 1.3TB mam volne, takze tam asi nie je dovod sa zasekavat. Samozrejme mohlo tomu "pomoct" to, ze je to VPS a aj ked je definovana ako dost rychla - vid spec niekde hore vo vlakne, zhodou okolnosti na rovnakom zeleze bezalo nieco naozaj narocne v inom VPS a tym padom to ovplyvnilo aj mna az to islo do kolien.