VPS hang

[chachaker]

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.

[ajankovic]

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?

[chachaker]

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.

[Dzonny]

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...

[chachaker]

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:

[mysqld]

log-slow-queries
safe-show-database

u

[mysqld]
set-variable = max_connections=300
log-slow-queries
safe-show-database
wait_timeout = 60
key_buffer = 128M
table_cache = 512

Od situacije da nam je server pucao na manje od 24 sata dosli smo u podnosljiviji rezim od restarta jednom nedeljno (kako sada stoje stvari), koji ce na kraju verovatno resiti dodavanje RAM-a na serveru. Ako neko ima jos saveta kako bi se ovaj fajl mogao dodatno optimizovati bio bih zahvalan na tome.

[serge]

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.)

SHOW VARIABLES LIKE  '%slow%'

i onda vidite vrednost varijable slow_query_log_file (meni je lokacija loga npr /var/lib/mysql/server-slow.log)

Sve u svemu, na 300 posetioca, VPS od 512MB bi morao da bude dovoljan.

[chachaker]

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.

[serge]

Meni zadnja linija u tom logu je

# Time: 130119 15:46:09
# User@Host: ***********[*******] @ **********[]
# Query_time: 12.539435  Lock_time: 0.000123 Rows_sent: 10  Rows_examined: 2832
SET timestamp=1358628369;
SELECT SQL_CALC_FOUND_ROWS  wp_posts.ID FROM wp_posts  WHERE 1=1  AND (((wp_posts.post_title LIKE '%lions%') OR (wp_posts.post_content LIKE '%lions%') OR (wp_posts.post_content REGEXP '\\[table id=(["\']?)(3|13|15|16)(["\' ])')) AND ((wp_posts.post_title LIKE '%arch%') OR (wp_posts.post_content LIKE '%arch%') OR (wp_posts.post_content REGEXP '\\[table id=(["\']?)(3)(["\' ])')))  AND (wp_posts.post_password = '')  AND wp_posts.post_type IN ('post', 'page', 'attachment') AND (wp_posts.post_status = 'publish')  ORDER BY wp_posts.post_date DESC LIMIT 0, 10;

Tacno se vidi datum query-ja, kao i duzina izvrsavanja (u sekundama). Ako ti imas slican query sa velikom duzinom izvrsavanja u zadnjim linijama, on bi mogao da bude uzrocnik zabadanja VPS-a.

[chachaker]

Hvala serge, ipak sam ja pocetnik za ovaj nivo. Identifikovao sam logove baze koja mi je sumnjiva.

SELECT arhiva.*, list.* FROM list LEFT JOIN arhiva ON list.InvertarniBroj = arhiva.arhivaid WHERE arhiva.VrstaGradje LIKE '%5%' AND ( arhiva.Autor 

LIKE '%pamela%' AND arhiva.Autor LIKE '%aidan%') GROUP BY arhiva.arhivaid LI$
# Time: 130116 19:05:28                                                                                                                            

                                                                             
# User@Host: * @ localhost []                                                                                       

                                                                             
# Query_time: 11.257197  Lock_time: 0.000077 Rows_sent: 10  Rows_examined: 37356                                                                   

                                                                             
SET timestamp=1358359528;                                                                                                                          

                                                                             
SELECT arhiva.*, list.* FROM list LEFT JOIN arhiva ON list.InvertarniBroj = arhiva.arhivaid WHERE arhiva.VrstaGradje LIKE '%4%' AND ( 

list.Odrednice LIKE '%остра%') LIMIT 140, 10;                                             
# Time: 130117 19:51:55                                                                                                                            

                                                                             
# User@Host: * @ localhost []                                                                                       

                                                                             
# Query_time: 11.061628  Lock_time: 0.000079 Rows_sent: 0  Rows_examined: 46709                                                                    

                                                                             
SET timestamp=1358448715;                                                                                                                          

                                                                             
SELECT arhiva.*, list.* FROM list LEFT JOIN arhiva ON list.InvertarniBroj = arhiva.arhivaid WHERE arhiva.VrstaGradje LIKE '%%' AND ( 

list.Odrednice LIKE '%ana%' AND list.Odrednice LIKE '%karenjina%');                        
# Time: 130117 21:11:30                                                                                                                            

                                                                             
# User@Host: * @ localhost []                                                                                                     

                                                                             
# Query_time: 476.310182  Lock_time: 0.000026 Rows_sent: 27726  Rows_examined: 27726                                                               

                                                                             
SET timestamp=1358453490;                                                                                                                          

                                                                             
SELECT * FROM `*`.`list`;                                                                                                               

                                                                             
# Time: 130117 21:38:34                                                                                                                            

                                                                             
# User@Host: * @ localhost []                                                                                                     

                                                                             
# Query_time: 266.563287  Lock_time: 0.000026 Rows_sent: 46709  Rows_examined: 46709                                                               

                                                                             
SET timestamp=1358455114;                                                                                                                          

                                                                             
SELECT * FROM `*`.`list`;

Ono sto sam pirmetio je i veiki broj logova vezanih za dve WordPress baze koje koristimo, bas u periodu kada smo imali intenzivirane pomenute probleme. U poslednjih nedelju dana tih logova vise nema, ostaju ovi gornji koji se ticu baze koja gura digitalnu biblioteku.

[serge]

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 `*`?