MySQL i koriscenje vise jezgara

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.

Potpis

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

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

Potpis

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

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

Lokuje li select upit tabelu... ?

Potpis

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

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

Potpis

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

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

Potpis

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

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.

Potpis

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

Zahvaljujem na odgovoru... pozdrav

Potpis

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

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

Potpis

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

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



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

Potpis

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