VPS hang
Pozdrav,
S vremena na vreme VPS server koji koristimo postane nedostupan, svi servisi su nedostupni i jedina pomoc je restart od strane hostinga. U pocetku smo se nagadjali mi i oni do koga je, receno nam je da MySQL baza koju koristimo nije optimizovana (sto je istina, jer nikada optimizaciju nismo radili niti znam to da uradim). U svakom slucaju prebacili su nas tada na drugi server i radilo je ok. Od pre nekoliko nedelja isti simptomi, a pocelo je sve sa neuspesnim automatskim update-om cPanela, sto se moze videti i u poruci koja mi stize na mejl svake nedelje: cPanel update hanging cPanel on b... Dec 24 (3 days ago) /usr/local/cpanel/scripts/upcp was running as pid '13263' for longer than 6 hours. cPanel will kill this process and run a new upcp in its place. cPanel on b... Dec 24 (3 days ago) /usr/local/cpanel/scripts/upcp was running as pid '14623' for longer than 6 hours. cPanel will kill this process and run a new upcp in its place. Takodje tu je i izvestaj o hang procesu (jedan od mnogih): The chkservd sub-process with pid 17768 ran for 15218 seconds. This sub-process was terminated when it exceeded the time allowed between checks, which is 300 seconds. To determine why, you can check /var/log/chkservd.log and /usr/local/cpanel/logs/tailwatchd_log. Primary IP: Service: chkservd Notification Type: hang Memory Information: Used: 481MB Available: 18MB Installed: 497MB Load Information: 245.49 252.75 260.78 Uptime: 2 days, 11 hours, 11 seconds IOStat Information: avg-cpu: %user %nice %system %iowait %steal %idle 2.16 1.55 20.71 16.06 0.00 59.52 Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn sda 347.13 11341.42 1177.19 1996016744 207178474 sda1 0.00 0.08 0.00 13978 6 sda2 111.25 4609.82 132.64 811298490 23342912 sda3 235.74 6731.31 1041.58 1184666566 183310632 sda4 0.00 0.00 0.00 18 0 sda5 0.13 0.21 2.98 37244 524924 ChkServd Version: 15.1 Da li neko moze iz gornjih podataka da mi razjasni eventualne uzrocnike problema, kako bih znao sta dalje ciniti. Proverio sam i log fajlove ali meni to nije razumljivo. Da napomenem da na shared hostingu koji smo koristili (druga firma) nije bilo ovakvih problema niti ovako ucestalih, a preselili smo se zbog prostora koji nam je trebao. |
Koliko vidim VPS ima malo operativne memorije pa sistem pokušava da nadoknadi tako što će da koristi hard disk za swap-ovanje. Ovo ti se nije dešavalo na shared-u zato što se tamo koristi pun kapacitet servera dok se ne popuni drugim korisnicima.
Najjednostavnija stvar koju možeš da uradiš je povećanje RAM-a ali zavisno od toga koliko imaš poseta i koju aplikaciju koristiš na serveru definitivno ti je potrebna i optimizacija servera. Znači neki cache ka klijentima i podešavanje parametara za MySQl. Koliko imaš poseta i koji ti je setup na serveru? |
Hvala na brzom odgovoru.
Specifikacije servera su: CentOS, 1 core CPU, 512 RAM, 40GB SATA2 HDD, 500 GB mes. protok. Sto se tice posete ona je niska, na nivou oko 300 jedinstvenih dnevno, sa relativno velikim brojem otvaranja stranica i pogodaka, jer hostujemo jednu digitalnu biblioteku sa velikim brojem skeniranih stranica i pretrazivacem. Hosting je rekao da nasa poseta ne bi trebalo da bude opterecenje za VPS. I ja mislim da je RAM problem, jer ga nesto jede. Mozda je to MySQL baza digitalne biblioteke, koja je negde oko 150MB ali nije radjeno na njoj otkad je napravljena. U njoj je 50.000+ zapisa u jednoj tabeli, a veliki broj zapisa sadrzi polja za pretragu punog teksta, znaci dosta karaktera. Ne razumem se se bas u SQL upite, ali sigurno bi trebalo nesto uraditi povodom optimizacije i kesiranja. |
300 poseta i nije neka poseta i to definitivno ne bi trebalo da opterećuje VPS. Pokušaj kao što je rekao kolega gore sa nekim cache softverom (npr XCache) za početak... 512mb RAM-a i nije nešto, mada mislim da može da prodje sa ovim posetama ako malo poradiš na optimizaciji...
|
Ako se slican problem javi i drugima, a nisu u mogucnosti da dokupe veci paket ili vise memorije na serveru, sto je nas slucaj, kao jedno od resenja moze da bude podesavanje /etc/my.cnf fajla.
Prema uputstvu sa http://blog.jambura.com/2011/09/10/t...ile-for-mysql/ promenio sam taj fajl od: Citat:
Citat:
|
Nesto je vama tu jako lose napisano u kodu. Ovo meni smrdi na neki neoptimizovani query koji "ubije" server. Dodavanjem ovog wait_timeout i postavljanjem na 60 ste verovatno sprecili zabadanje servera time sto mysql ubije problematicni query posle 60 sekundi i stvari se vrate u normalu. Problem je u tome sto time krajnji korisnik takodje ne dobije trazenu stranicu a i verovatno mu se ispise greska tipa "mysql server has gone away".
Treba da se otvori slow query log i proveri tacno koji query pravi problem i da se pokusa optimizacija. Verovatno se ne koristi dobro index ili se join-uje puno tabela. Lokaciju slow quey log-a mozete da nadjete ako pustite query (u Phpmyadmin npr.) Kôd:
SHOW VARIABLES LIKE '%slow%' Sve u svemu, na 300 posetioca, VPS od 512MB bi morao da bude dovoljan. |
Uradio sam <SHOW VARIABLES LIKE '%slow%'> query za bazu koja mi je sumnjiva, ali u rezultatima dobijam log fajl koji ima 39.000 linija. Ono sto me zbunjuje je to da su u njemu i podaci za druge baze koje koristimo (kao sto su one za WordPress ili blog platforme), kao i one koje vise ne postoje/ne koriste se, ali ime jedne od tih bivsih baza i dalje vidim da se pojavljuje u logovima (doduse baza je uklonjena sa servera, dok je skripta foruma ostala na serveru, ne znam da li je to bitno reci).
Sto se tice ponasanja servera osim odredjenog usporenja u otvaranju stranica nismo primetili druge probleme za sada. Probao sam i da vrsim veci broj upita pretrage, nasumicno otvaranje rezultata pretrage, pregled fajlova, tokom viseminutnih proba, ali nisam dobio neku gresku. Da li da probam OPTIMIZE TABLE za svaku tabelu baze, jer vidim na http://dev.mysql.com/doc/refman/5.1/...ize-table.html da moze da pomogne u slucajevima cestog azuriranja podataka, brisanja itd. |
Meni zadnja linija u tom logu je
Kôd:
# Time: 130119 15:46:09 |
Hvala serge, ipak sam ja pocetnik za ovaj nivo. Identifikovao sam logove baze koja mi je sumnjiva.
Kôd:
SELECT arhiva.*, list.* FROM list LEFT JOIN arhiva ON list.InvertarniBroj = arhiva.arhivaid WHERE arhiva.VrstaGradje LIKE '%5%' AND ( arhiva.Autor |
Nesto tu nije normalno. Imas ovaj query:
SELECT * FROM `*`.`list` .. koji traje, jednom 476, a drugi put 266 sekunde, sto uopste nije normalno. Posebno ako se vidi da se povuce prvi put 27726, a drugi put 46709 redova. To ne bi trebalo da traje tih 5-8 minuta. Takodje se vidi da se broj redova u tabeli list povecao za 20.000 u roku od 27 minuta sto znaci da je bilo bas puno inserta u medjuvremenu. Mozda nema nikakve veze sa mysql-om? Mozda imas neki proces u pozadini koji puni tu list tabelu pa tu nesto pada (neki cron mozda?). Probaj sa tim OPTIMIZE table i REPAIR table ali prethodno backup svega ;) P.S. ko naziva svoju bazu `*`? |
Citat:
Toliki broj inserta nije moguc za 27 minuta, videcu sta je u pitanju. Takodje cu odraditi OPTIMIZE i REPAIR za tabele, pa cu javiti rezultate. Da dodam i pozitivnu vest da server radi sve ove dane (pu pu, da ga ne ureknem). Nije * naziv baze, to sam ja zamenio pravi naziv u postu pre objavljivanja na forumu. Paranoja, Veliki brat posmatra, sta ces... |
Posto sam rekao da cu javiti rezultate optimizacije baze podataka evo i toga. Uradjene su komande optimize i repair table, dok je autor baze proverio neke najcesce koriscene fajlove skripte (za pretragu) i "Dodao sam neke dodatne provere na ove stranice sto ti saljem kako nebi doslo do nekog injection-a pa da se zbog toga lose generise query.
Takodje sam na ove stranice koje se najvise upotrebljavaju dodao pozive mysql funkcija kako bi se oslobodila memorija." Vise nemamo problema sa zakivanjem servera, a i poruke o Hang-u servera vise nema, pa racunam da je za sada problem resen. Za narednu budzetsku godinu verovatno cemo ukalkulisati poboljanje paketa VPS-a koji koristimo i dodavanje RAM memorije. Pozdrav |
Vreme je GMT +2. Trenutno vreme je 04:03. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.