[es] - MySQL i koriscenje vise jezgara

Tyler Durden
Tyler Durden
Beograd

Član broj: 4312
Poruke: 3379
*.verat.net.

+1365 Profil

^{02.06.2010. u 14:59 - pre 169 meseci}

Imam server sa vise baza i vise servisa koji koriste razlicite baze. Server ima 2x dual core Xeone.
Desava se da kad zabodem sa jednim upitom jednu bazu, % na jednom jezgru skoci na 100 i sasvim drugi servis koji koristi istu bazu ne moze uopste da dodje na red dok se ovaj upit ne zavrsi, bez obzira sto ostala jezgra kuliraju na 0% zauzetosti. Servisi koji koriste drugu bazu rade ok.

To mi je malo cudno, djeluje kao da citava baza bude "zakljucana". Jel to ocekivano ponasanje ili je neka greska u podesavanju?
MyISAM engine je u pitanju.

Beneath civilization's fragile crust, cold chaos churns...

Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.31.24.217.adsl2.beograd.com.

Sajt: mysql.rs

+2377 Profil

Re: MySQL i koriscenje vise jezgara

^{02.06.2010. u 22:29 - pre 169 meseci}

1. jedan upit na mysql serveru se izvrsava uvek u jednom tredu.
2. jedan tred moze da trci samo na jednom procesoru u jedno vreme.
3. myisam ima samo table locking

1+2 = ako imas upit koji smara cpu taj upit ce zabosti jedan cpu (jezgro) a ostala jezgra ce piti kafu i cekati da ih neki drugi tred pozove na igranku
1+2+3 = ako upit koji dugo traje menja neke podatke nad tabelom, taj upit ce tu tabelu zakljucati (celu) tako da ce svi ostali upiti koji imaju sta pitati tu istu tabelu sedeti zajedno sa onim slobodnom jezgrima i grickati semenke dok ovaj dugotrajni smarac ne zavrsi svoje i ne odkljuca tabelu

resenje = videti "sta" drzi "koga" zakljucanim, sledeci put kad se tako zabode a ti pukni jedan "show full processlist" pa vidi koji procesi "piju kafu" a koji "vodi koju tabelu u bioskop", onda razmisli da li ti se isplati da tu tabelu bacis u innodb (koji ima row level locking te dozvoljava da razlicite delove tabele istovremeno menja vise tredova) ili da prepises tog svalera da radi malo drugacije / brze

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Odgovor na temu

stevs986
Nikolic Sladjan
Senior Software Developer
Alterset d.o.o
Beograd

Član broj: 121154
Poruke: 140
*.dynamic.sbb.rs.

+4 Profil

Re: MySQL i koriscenje vise jezgara

^{02.06.2010. u 23:56 - pre 169 meseci}

Da priupitam i ja nesto na brzaka... :) onako usput...

Lokuje li select upit tabelu... ?

Linkedin: http://www.linkedin.com/in/sladjannikolic
Twitter: https://twitter.com/_SladjanNikolic

Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.31.24.217.adsl2.beograd.com.

Sajt: mysql.rs

+2377 Profil

Re: MySQL i koriscenje vise jezgara

^{03.06.2010. u 00:08 - pre 169 meseci}

naravno ... e sad, kakav lock, to zavisi od storage engine-a, vrste select-a i slicno ..

za myisam, select uzima "read lock" (odnosno, ne uzima lock nego samo sprecava kreiranje exclusive lock-a) sto znaci da drugi selectovi mogu da rade paralelno (select for update na myisam-u nema mnogo smisla). Ono sto je nezgodno kod myisam-a je ako imas

SELECT (A)
UPDATE
SELECT (B)

sada dok traje ovaj select(A) bi bez problema mogao da trci i SELECT(B) ali posto update ima veci prioritet on ceka na exclusive lock nad tabelom dok se select(a) ne zavrsi, onda ce on da odradi sta ima (update) i onda ce tek select (b) da radi. Teoretslo ke select(b) mogao ranije da se izvrsi - al ... e sad, to resavas tako sto koristis update niskog prioriteta (imas opciju u configu) te ce onda select(b) da se izvrsi odma (nece cekati update) - problem ovde je sto ako imas puno select-a, update ce "mnogo dugo" da ceka na red...

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.31.24.217.adsl2.beograd.com.

Sajt: mysql.rs

+2377 Profil

Re: MySQL i koriscenje vise jezgara

^{03.06.2010. u 00:09 - pre 169 meseci}

vezano za lokovanje procitaj malo: http://dev.mysql.com/doc/refman/5.5/en/locking-issues.html

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Odgovor na temu

Tyler Durden
Tyler Durden
Beograd

Član broj: 4312
Poruke: 3379
*.verat.net.

+1365 Profil

Re: MySQL i koriscenje vise jezgara

^{03.06.2010. u 08:06 - pre 169 meseci}

Mmmm, mislim da je jasno sada i koliko vidim morace to da se prebaci na innodb.
Ovaj smaracki upit je SELECT, a upiti koji stalno pice i po nekoliko u sekundi, i koji bivaju odsjevani su UPDATE-i i INSERT-i.

Beneath civilization's fragile crust, cold chaos churns...

Odgovor na temu

stevs986
Nikolic Sladjan
Senior Software Developer
Alterset d.o.o
Beograd

Član broj: 121154
Poruke: 140
*.kbcnet.rs.

+4 Profil

Re: MySQL i koriscenje vise jezgara

^{03.06.2010. u 11:12 - pre 169 meseci}

Citat:

bogdan.kecman: naravno ... e sad, kakav lock, to zavisi od storage engine-a, vrste select-a i slicno ..

za myisam, select uzima "read lock" (odnosno, ne uzima lock nego samo sprecava kreiranje exclusive lock-a) sto znaci da drugi selectovi mogu da rade paralelno (select for update na myisam-u nema mnogo smisla). Ono sto je nezgodno kod myisam-a je ako imas

SELECT (A)
UPDATE
SELECT (B)

sada dok traje ovaj select(A) bi bez problema mogao da trci i SELECT(B) ali posto update ima veci prioritet on ceka na exclusive lock nad tabelom dok se select(a) ne zavrsi, onda ce on da odradi sta ima (update) i onda ce tek select (b) da radi. Teoretslo ke select(b) mogao ranije da se izvrsi - al ... e sad, to resavas tako sto koristis update niskog prioriteta (imas opciju u configu) te ce onda select(b) da se izvrsi odma (nece cekati update) - problem ovde je sto ako imas puno select-a, update ce "mnogo dugo" da ceka na red...

Zahvaljujem na odgovoru... pozdrav

Linkedin: http://www.linkedin.com/in/sladjannikolic
Twitter: https://twitter.com/_SladjanNikolic

Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.31.24.217.adsl2.beograd.com.

Sajt: mysql.rs

+2377 Profil

Re: MySQL i koriscenje vise jezgara

^{03.06.2010. u 13:52 - pre 169 meseci}

da innodb je tu mnogo snalazljiviji ... doduse, ono o cemu mozes da razmislis je da optimizujes taj smaracki select :) ..

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Odgovor na temu

Tyler Durden
Tyler Durden
Beograd

Član broj: 4312
Poruke: 3379
*.verat.net.

+1365 Profil

Re: MySQL i koriscenje vise jezgara

^{03.06.2010. u 15:09 - pre 169 meseci}

Ne znam sta bih mogao da optimizujem u upitu koji mi se cini prilicno prost.

Code:
SELECT sum(c1) as d, MONTHNAME(c2) AS m from t1 group by m

a u tabeli t1 se nalazi vise od 3 miliona rekorda.

Beneath civilization's fragile crust, cold chaos churns...

Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.31.24.217.adsl2.beograd.com.

Sajt: mysql.rs

+2377 Profil

Re: MySQL i koriscenje vise jezgara

^{03.06.2010. u 15:34 - pre 169 meseci}

AUCH!!

ovaj upit ti SVAKI PUT radi FULL TABLE SCAN :( ... sto zato sto je mysql glup sto iz drugih razloga .. posto je `m` rezultat funkcije, sve i ako imas index po c1 mysql ne ume da ga koristi tako da ide bukvalno red po red kroz svih 3 miliona vadi monthname() i racuna ...

posto nema nikakav where, tebi u svakom slucaju treba full table scan tako da cak i ako bi dodao kolonu c3 u kojoj bi cuvao monthname ne bi imao nikakvo ubrzanje posto bi opet isao kroz celu tabelu, ono sto do duse mozes da uradis je da napravis tabelu `sum_po_mesecima` koja bi imala "monthname" i "zbir" i koju bi odrzavao trigerom (nad t1 napravis triger nad insert/update i delete koji u zavisnosti od operacije radi ++ ili -- nad onom tabelom sa 12 redova ... na taj nacin nemas vise taj ocajni select koji ti zabada celu bazu ... a inserti i update-i nad t1 su neznatno usporeni

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Odgovor na temu