Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

Optimizacija mySQL servera

[es] :: MySQL :: Optimizacija mySQL servera

Strane: 1 2

[ Pregleda: 12627 | Odgovora: 39 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

mojeKorIme
BiH

Član broj: 59512
Poruke: 350
92.36.254.*



+1 Profil

icon Optimizacija mySQL servera06.03.2009. u 11:39 - pre 183 meseci
Pozdrav,
u razgovoru sa Bogdanom sam se zapitao koja je to optimalna postavka mySQL servera. (ovim putem se zahvaljujem Bogdanu koji mi je bio od veeeeliiike pomoci - isprintacu njegovu sliku i staviti je pored Nikole Tesle:) ).

Vracam se na pitanje:
- kako podesiti optimalne postavke za mySQL server u odnosu na PC/server (njihove komponente - processor, RAM, HDD)
na što treba obratiti pažnju kada imamo slabiju konfiguraciju, a gdje se možemo "razbacivati" ako imamo extra hardware?


hvala unaprijed
Give me six hours to chop down a tree and I will spend the first four sharpening the axe.
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.xdsl.beograd.com.

Sajt: mysql.rs


+2377 Profil

icon Re: Optimizacija mySQL servera06.03.2009. u 20:06 - pre 183 meseci
da pocnem sa omiljenim citatom "there is no silver bullet" .. dakle, ne postoji unverzalno resenje ali neke "osnove" vezano za optimizaciju:

neki uvod:
- sve sto napisem u ovom postu vazi za linux, solaris i ostale unixolike sisteme, ako terate db server na windozama vi nemate potrebu da taj db server bude optimizovan, ali vecina stvari iz ovog posta moze da se primeni i na windoze
- DB server treba da bude dedicated. Nije obavezno, nije neophodno, ali za iole ozbiljniji DB server - ocekuje se da je to jedini app koji se vrti na masini

neke osnove:
ako zanemarimo klaster koji je posebna kategorija i nema mnogo veze sa obicnim mysql-om .. treba da obratimo paznju na osnovna 3 resursa koja su bitna za bazu podataka:
1. CPU
2. RAM
3. IO

CPU
- kada je MySQL u pitanju, jedna konekcija je jedan thread, dakle jedna konekcija / jedan upit ne moze da iskoristi vise od jednog jezgra
- kada je MySQL u pitanju, sorage enginei kao i sam kor mysql-a se JAKO LOSE SKALIRA ... max procesorskih jezgara koji MySQL ume da iskoristi je 8 (da, osam), sve preko toga samo "smeta" ..
- baze podataka RETKO KORISTE CPU, tj, vrlo retko ce vam usko grlo na serveru biti CPU

RAM
- sto vise rama to bolje :D
- MySQL ima nekoliko "storage engine-a", od "siroko koristenih" i "dzaba" su bitni MyISAM i InnoDB. MyISAM NIJE transakcioni engine dok InnoDB to jeste. SVE transakcije su MEMORY BASED, znaci, ako nema dovoljno rama da se cela transakcija izvrsi u ram-u - transakcija nece proci. Primer, ako imas tabelu od 2G i uradis u jednoj transakciji promenu cele tabele, dakle imas 2G izmena a imas samo 1G slobodnog ram-a, transakcija nece proci
- mysql ume da kesira rezultate u ram-u
- mysql uma da kesira pristup disku u ram-u

IO
- ovo je glavno usko grlo svake baze podataka, podaci se nalaze na disku i odatle ih treba procitati.
- tek kada se podaci fizicki zapisu na disk i dobije potvrda o tome - podaci su sigurni
- u IO spada i mreza, slanje i primanje paketa kroz mrezu isto opterecuje IO sistema

neke optimizacione osnove vezane za mysql bazirane na osnovama malopre pomenutim

1. CPU - ovde nema sta mnogo reci ... uzeti server sa vise od 8 jezgara da bude mysql server je "bacanje para", 4 jezgra je idealno, dakle, za mysql, mnogo bolje ce posao raditi dual core na 4GHz nego 16core masina na 2GHz ...

2. RAM
podesiti swappiness parametar kernela (linux) na 0 (default od 60 je ok za desktop ali zastrasujuce los za server), slican parametar postoji i za ostale unix-e

dati InnoDB-u sto vise rama za innodb_buffer_pool_size. To je bafer gde innodb kesira pristup disku, on to sam mnooogo bolje radi nego sistem cache tako da mu treba dati sto vise rama ovde. Za InnoDB only sistem 70-80% ram-a je idealna cifra, za sisteme koji nisu 100% innodb (dakle koriste i MyISAM ili neke druge storage engine) neka manja cifra je ok

query cache
- za sisteme sa mnogo vecim odnosom read : write veliki query_Cache je super stvar (kesira rezultate upita), (do 1G)
- na sistemima gde postoji veliki broj upisa/promena koriscenje "query hintova" gde se mysql-u kaze koje upite da kesira a koje ne je uputno uz veliki query cache (100M - 2G)
- na sistemima gde je broj upisa veliki i nad istim je podacima kao citanje, query cache treba ugasiti ili setovati na vrlo malu cifru (1-3M)
Ako ne znas sta i kako, ok je staviti nekih 10-20M pa pratiti query cache hit ratio
ostali baferi .. ostale bafere podesiti vezano za upotrebu aplikacije - ovde ne postoje "generalni saveti"

3. IO
- NEMOJTE KORISTITI NAS za storage subsystem, SAN je ok ali NAS ubija performanse jaaaako
- za MyISAM razdvojite indexe od podataka na razlicite spindlove (na razlicite diskove - ne razlicite particije istog diska)
- za InnoDB log bacite na razlicite spindlove od onih gde je data fajl
- LVM ne sluzi nicemu ako koristiti InnoDB
- za InnoDB koristite ODIRECT kako bi zaobisli duplo kesiranje (izbegnete kesiranje fajl sistema) na linuxu
- InnoDB podatke stavite na "forcedirectio" particiju na solarisu (slicno kao ODIRECT na linuxu)


toliko za sada ... spremam malo "opsezniji" tekst EDIT: http://mysql.crsndoo.com/wp/2009/03/optimizacija-mysql-servera/ eto ga tu ...



[Ovu poruku je menjao bogdan.kecman dana 07.03.2009. u 00:19 GMT+1]
 
Odgovor na temu

Schmidt
RHCE

Član broj: 80784
Poruke: 647
*.poen.net.



+10 Profil

icon Re: Optimizacija mySQL servera07.03.2009. u 09:23 - pre 183 meseci
Procitao sam i sad su neke stvari jasnije :) Koja je cijena MySQL Enterprise Monitora da mogu nadredjenima napraviti prijedlog za kupovinu? Da li monitor moze pratiti vise servera odjednom? Svakako cu probati testnu verziju ali vikend je i znatizelja me izjeda :)
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.xdsl.beograd.com.

Sajt: mysql.rs


+2377 Profil

icon Re: Optimizacija mySQL servera07.03.2009. u 12:58 - pre 183 meseci
Citat:
Schmidt: Procitao sam i sad su neke stvari jasnije :)

drago mi je :)
pogledaj i ono ovde posto je to malo "drugacije organizovana" ali vise manje ista prica ... (ovo na ovom forumu sam cukao iz glave a ono tamo sam kao prvo nacukao u txt editoru, prisredio pa ..)
ako ima dodatnih pitanja ... "do not hesitate"

Citat:
Koja je cijena MySQL Enterprise Monitora da mogu nadredjenima napraviti prijedlog za kupovinu? Da li monitor moze pratiti vise servera odjednom? Svakako cu probati testnu verziju ali vikend je i znatizelja me izjeda :)

ja se ubih smarajuci odgovarajuce strukture u sun-u po ovom pitanju ali sam u manjini. vec sam vise puta na nasim internim listama obrazlozio kako bi izdvajanje merlina bilo vrlo dobar potez i kako ima veliki broj ljudi koji bi platili da imaju merlin .. no .. za sada nista od toga.

merlin je "dzaba" za nekoga a nedodirljiv za nekog drugog. sta to znaci, ako imas mysql enterprise subscription - uz nju dobijes merlin: http://www.mysql.com/products/enterprise/features.html
zavisno od nivoa servisa koji uzmes - takav set "saveta" dobijes uz merlin, dakle sam monitoring (logovi, grafovi, stanja) ima svako, a "saveti" (na primer, "povecaj innodb_buffer_pool" ili "smanji sort_buffer") su bazirani na nivou subscription-a tako da postoji 3 seta "advisory rules" koje mozes da imas.

merlin moze da prati mnogo servera odjednom, imamo klijente koji prate 20K servera jednim merlinom, merlin dozvoljava da pratis onoliko servera za koliko servera imas enterprise subscription

pogledaj: http://www.mysql.com/products/enterprise/monitor.html
i obavezno: http://www.mysql.com/products/enterprise/benefits.html


pvde prati 6 servera odjednom - pocetna strana:


analizator upita:



replication monitor:


saveti:





 
Odgovor na temu

Schmidt
RHCE

Član broj: 80784
Poruke: 647
*.poen.net.



+10 Profil

icon Re: Optimizacija mySQL servera07.03.2009. u 18:10 - pre 183 meseci
Kakav alat, kakva steta. Steta je takodje sto nije problem da se takav proizvod plati. Malo je bezobrazno da te tjera da kupis Enterprise server da bi mogao da imas ovako dobru analizu rada servera :( Ali, sta sad, nije toliki problem zivjeti bez necega bez cega se moze. U svakom slucaju drzacu se tvojih preporuka, na kojim sam mnogo zahvalan :)
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.xdsl.beograd.com.

Sajt: mysql.rs


+2377 Profil

icon Re: Optimizacija mySQL servera07.03.2009. u 20:17 - pre 183 meseci
Citat:
Schmidt: Kakav alat, kakva steta. Steta je takodje sto nije problem da se takav proizvod plati. Malo je bezobrazno da te tjera da kupis Enterprise server da bi mogao da imas ovako dobru analizu rada servera :(


mi zivimo od support-a, sve ostalo je added value .. to je "company policy" od kada postoji mysql... e sada, slazem se da su neki od tih "added value" kompletni i odlicni proizvodi i da bi bilo super imati ih zasebno .. no sta je tu je .. rekoh da sam se od prvog dana zalagao za izdvajanje merlina kao zasebnog proizvoda (interni naziv za enteprise monitor je merlin - a tako se zvao i u startu - sada je NMAS / MEM / Enterprise Monitor)... no .. sta je tu je... taj "enterprise server" je isto value added service, ti njega ne kupujes, enterprise binary je isto "adde value" uz podrsku...

ono sto je zgodno napomenuti je da je support prilicno "jeftin".. posebno ako se uzme u obzir kvalitet podrske i sta ona sve daje kao added value ... pogledaj http://www.mysql.com/products/enterprise/features.html

za 4000E godisnje (ispod 350E mesecno) po serveru dobijes (pored ostalih "standardnih stvar")
- Remote Troubleshooting - dakle, ja se okacim na tvoj server, pronadjem gde je problem i popravim ga ..
- Replication Review - provera da li replikacija radi kako treba, da li je nasetovano sve kako treba, da li koristis upite koji su problematicni, da li moze optimalnije ...
- Partitioning Review - provera da li partitioning radi kako treba ... ---||---
- Query Review - posaljes nam upit i mi ti kazemo da li je ok, zasto nije, da li moze bolje, kako moze bolje
- Schema Review - posaljes na db model, mi ti kazem da li je ok, zasto nije, da li moze bolje i kako moze bolje
- Performance Tuning - nasiljimo ti server da bude najbrzi moguci za tvoje specificne potrebe
- Customer Code Reviews: MySQL Client APIs - ne radi ti kod, posaljes nam sors i mi ga popravimo
- Customer Code Reviews: MySQL User Defined Functions & Server Extensions - --||--
- Customer Code Reviews: MySQL Stored Procedures, Triggers & Functions --||--

ako uzmemo u obzir da jedan prosecan dbadmin koji ovo sve ne ume da radi ni 1% dobro koliko to mi radimo kosta u beogradu 1200E netto, dakle jedno 2000E brutto MESECNO mislim da je kalkulacija vrlo jednostavna .. da ne spominjemo koliko taj isti dbadmin kosta u "razvijenom svetu" ...

Inace limit na broj servera u samom merlinu je "warning", bar za sada, dakle, ako imas pravo na 1 server a monitorujes 10, merlin ti kaze "warning: imas pravo da monitorujes 1 server a monitorujes 10, molim te da proveris licencu" .. i sve "radi" .. e sad, to mozda vec u sledecoj verziji ne bude tako, mozda prvih 10dana bude warning pa onda prestane da radi .. mozda odma .. mozda ... nebitno - sada je samo upozorenje
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.xdsl.beograd.com.

Sajt: mysql.rs


+2377 Profil

icon Re: Optimizacija mySQL servera07.03.2009. u 20:23 - pre 183 meseci
inace, fora koju dosta firmi iz zemalja poput srbije (zimabwe, jordan, kazahstan, tadzikistan, turkmenistan, kongo...) koristi je da uzme probnu verziju merlina, prati tih 30 dana svoj server, i iskoristi te podatke da ga optimizuje, onda nikad ne kupe "pravi proizvod".... moram priznati da je preko 90% njih koji uzmu trial uzelo isti sa tom idejom ... ono sto je tu super je sto preko 50% njih ostanu korisnici posto odlepe na proizvod i shvate da vredi svaki dinar (nemacki, americki ili kojim vec dinarima placaju) :)
 
Odgovor na temu

Schmidt
RHCE

Član broj: 80784
Poruke: 647
*.poen.net.



+10 Profil

icon Re: Optimizacija mySQL servera07.03.2009. u 22:15 - pre 183 meseci
Izvini, sad sam tek shvatio kako je mogao zvucati moj prethodni post. Nisam htio da optuzujem, samo sam htio da konstatujem da bi stvarno bilo super da merlin mogu da kupim bez enterprise licence. Za sada nemam problema sa hardverom, nemam problema sa opterecenjem baze, i ako se nesto desi ipak sve uspijem rijesiti malim pregledom koda, pa zbog toga nije primarno da moram imati takav vid podrske ili placati MySQL Enterprise. S vremenom cu vjerovatno doci na taj nivo, za sada je ok. Ali, merlin bi mi sada vrijedio, kao neka "prva stepenica". Opet, s druge strane, razumijem i da ga se ne moze nabaviti bez kupovine Enterprise editiona jer, pored svega sto sam vidio na printscreenovima, vjerovatno mi ne bi palo na pamet da kupim Enterprise Edition samo zbog bolje podrske jer, merlin bi odradio masu stvari prije nego sto bi zatrebala dodatna podrska. U svakom slucaju dobar proizvod i posebne pohvale tebi na spremnosti da objasnis sve sto te pitamo :)
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.xdsl.beograd.com.

Sajt: mysql.rs


+2377 Profil

icon Re: Optimizacija mySQL servera07.03.2009. u 22:48 - pre 183 meseci
Citat:
Schmidt: Izvini, sad sam tek shvatio kako je mogao zvucati moj prethodni post. Nisam htio da optuzujem, samo sam htio da konstatujem da bi stvarno bilo super da merlin mogu da kupim bez enterprise licence.


ja mislim da sam te potpuno pravilno razumeo - ja isto mislim da bi bilo mnogo iskusno da moze da se kupi kao zaseban proizvod, rekoh da sam se zalagao za to i objasnih zasto je to sada tako kako je .. alat je extra, nisam siguran kako ide varijanta sa "30day trial" ... znam da za to vreme mozes da postavis samo dva pitanja i da moraju da budu vezana za merlin, dakle ne moze "zasto mi je server spor" .. za to vreme valjda imas fully functional merlin ... e ne znam da li to kosta neke pare ili samo tamo popunis to i dobijes na testiranje ...
 
Odgovor na temu

Schmidt
RHCE

Član broj: 80784
Poruke: 647
*.blic.net.



+10 Profil

icon Re: Optimizacija mySQL servera09.03.2009. u 11:29 - pre 183 meseci
Da li je problem ako se koristi innodb odirect na LVM particiji? Prvenstveno, da li bi mogao biti problem ako mysql direktno pise na disk, a pritom odradim LVM snapshot radi nekog backupa, prebacivanja ili bilo cega slicnog? Da li su podaci u tom slucaju ispravni i da li su u opasnosti?
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.xdsl.beograd.com.

Sajt: mysql.rs


+2377 Profil

icon Re: Optimizacija mySQL servera09.03.2009. u 12:20 - pre 183 meseci
InnoDB je tu prilicno nezgodan ... tako da .. ja iskreno ne volim LVM ali ne postoji konsenzus .. samo cinjenice ..

u cemu je stvar, ako mysql-u na bilo koji nacin kazes da "prestane da pise po disku" da bi ti iskopirao sadrzaj - to za innodb prosto ne radi. sve varijante gde ti uradis flashovanje na disk i lokovanje tabela pri kopiranju innodb table space "nije cist" i ti kada vratis taj "bekap" mysql radi crash recovery, dakle cak i ako korists mylvmbackup, pitanje je samo da li ce skripta odma ili mysql kasnije da radi recovery .... "flush tables with read lock;" za innodb ne radi isto sto i za myisam...

moje licno misljenje, dakle, da ponovim, moje licno, je da to nije bekap. bekap treba da bude konzistentan i treba da bude u nekom trenutku u vremenu ... ako ja treba da radim "crash recovery" nad bekapom - **** bekap

ako zaboravimo taj bekap bez gasenja mysql-a, sa lvm-om je brze
- ugasis mysql
- odradis snapshot
- upalis mysql
- bekapujes snapshot
- obrises snapshot

dakle server jeste offline, ali je offline samo tokom pravljenja snapshot-a.... ako nemamo lvm, onda server mora da bude offline tokom kopiranja datadir-a na drugu lokaciju ... dakle nesto duze ... no ako uzmemo u obzir da optimalno podesen server radi "regularno gasenje" nekoliko minuta .. ceo taj proces uopste nije taka kratak i "down time" uopste nije mali sto jedan ozbiljan klijent sebi svejedno ne moze da dopusti.

tu je sada na tebi .. da li ces da pristanes na ~3-10% IO usporenja koja donosi LVM da bi radio brze bekap.

Ja sam uvek za varijantu da bekap pravis tako sto imas slave server, ugasis, napravis bekap na tenane .. a nikako za varijantu da trpis taj LVM overhead "non stop". Tu se samnom nece sloziti 50% ljudi u firmi .. PeterZ koji je jedan od poznatijih (ako ne i najpoznatiji) a i najvecih strucnjaka za optimizaciju rada mysql-a na primer zagovara koristenje LVM-a... on u startu datadir stavlja na LVM... ja se opek apsolutno protivim lVM-u ako se koristi innodb.

IO je najbitniji kod optimizovane baze .. uglavnom je tu usko grlo, tih 3-10% je, po meni, mnogo, posebno sto tih 3% ja nikad nisam video, nikada nisam izmerio ispod 7% a u nekoliko slucajeva sam merio i 15-20% usporenja (software raid + lvm na linuxu) ... ako dodatno uzmemo u obzir da mysql radi na online backup-u, to je prosto "layer viska"...
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.xdsl.beograd.com.

Sajt: mysql.rs


+2377 Profil

icon Re: Optimizacija mySQL servera09.03.2009. u 12:26 - pre 183 meseci
vezano za sigurnost ODIRECT-a ..

problem 1. https://bugzilla.redhat.com/show_bug.cgi?id=446599

dakle, ako kernel ima odirect bug - moze da bude belaja

problem 2. u nekim slucajevima - opet zbog problema sa kernelom - ovaj put feature a ne bug - ODIRECT moze da uspori select drasticno

tako da, O_DIRECT uvek mora da se "proba" .. to nije "default" bolja varijanta ... ako ne postoji o_difrect kernel bug - podaci su sigurni (cak i ako je fs na lvm-u; lvm tu samo usporava stvar nista drugo).. ako postoji kernel bug podaci su opet sigurni samo ce mysql da "rikne" ...

mysql ima tu foru da u slucaju da nije siguran sta se desava - rikne .. posto je filozofija "bolje da ja segfaultujem nego da upisem pogresne podatke na disk"
 
Odgovor na temu

Schmidt
RHCE

Član broj: 80784
Poruke: 647
*.blic.net.



+10 Profil

icon Re: Optimizacija mySQL servera09.03.2009. u 13:36 - pre 183 meseci
Dobro, kod mene ne bi trebalo da bude toliki procenat usporenja jer je u pitanju SCSI 15k na hardware-skom RAID-u. Pomenuo sam ti u PP kakav je racunar u pitanju, ali opet nije zgorega izvuci jos poneki promil performansi :) Backup je jako bitan i radi se cesto...

[Ovu poruku je menjao Schmidt dana 10.03.2009. u 14:19 GMT+1]
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.xdsl.beograd.com.

Sajt: mysql.rs


+2377 Profil

icon Re: Optimizacija mySQL servera09.03.2009. u 14:12 - pre 183 meseci
procenat je procenat :D .. sto je brzi HW to je procenat usporenja koji doda LVM veci :D (realno, LVM dodaje neke fiksne mikrosekunde tu tako da sto je storage subsystem brzi to su te mikrosekunde "Veci procenat")

sto se bekapa tice to je velika tema .. i prilicno ozbiljna ... sve u svemu - ja podrzavam varijantu "slave backup" .. dakle imas slave server koji samo za to koristis ... kad oces da uradis bekap, odvojis slave sa mreze, odradis bekap kako god ti milo i drago i vratis slave nazad na mrezu da sustgne mastera .. no ... ne bih sad ulazio u detalje posto je prica oko optimizacije servera a ne o pravljenju bekapa...

dodatno je bitno koji storage engine ... sa myisam-om lvm je super .. cak ponekad i neophodan, bekap myisam tabela sa lvm-om je pesma etc etc ... dok opet, innodb ima svoj "table space" koji moze da se baca okolo, koji je filesystem za sebe .. tako da tu osnovna prednost LVM-a (snapshot) ne pomaze :(

e sad .. imao sam prilike da vidim servere sa par desetina hiljada upita u minuti i par hiljada konkurentnih konekcija koji su "default" namesteni ... i ladno su na 10% CPU/IO iliti mogu jos 10* toliko bez da se primeti ... dok sam video i one koji imaju po 10 upita u minuti i kolje ih IO ili CPU ... imamo klijenta koji pravi dns aplikaciju .. u pozadini je mysql .. on ima po 300K upita u minuti :) i to jedna "pateticna" masina sa par giga rama i xeonom od pre 4 godine pljuje iz zezanja ... opet, sad se smaram sa nekim papanima .. ma .. sve ima svoje .. u 99% slucajeva, ponavljam se, optimizacija se svodi na dobro napravljen DB model.... kada pogledam kako ljudi prave tabele, od toga kakva imena koriste do toga sta sa cim stavljaju pripadne mi muka ....

jedan zanimljiv detalj .. covek, tehnicki direktor i "glavni developer" jedne velike (preko 100 zaposlenih, preko 6cifara mesecni obrt) firme u Londonu (nisu MySQL klijenti, ja sam im radio privatno konsaltin pre nego sam otisao u mysql) koji je u tu firmu dosao iz opet drzavne firme (neki inspektorat) gde je radio kao "senior developer" .... pita sledece:

imao sam
Code:

create table t1 (t1_id bigint auto_increment primary key, t1_start date, t1_flag int, t1_userid bigint, key d (f1_start), key f (t1_flag));

gde t1 ima nekih 200M slogova i upit:
Code:

select t1_userid from t1 where t1_flag = 1 and t1_date > now();


meni sada treba ovako nesto

Code:

select t1_userid from t1 where t1_flag = 1 and t1_date > now() and f1_userid>20 and f1_userid<200;


i sada upit traje 40 minuta?!?!?!? sta da radim???

ja se okacim na server (inace neki p1) i uradim "alter table t1 add key (f1_userid);" .. kazem mu da pusti upit i isti se izvrsi za manje od 1sec ... on zove krene da place i pita sta sam uradio ... ja mu lepo kazem "nista pametno, dodao sam index na polje po kom radis pretragu" ... na to dobijem odgovor "why did that help"!!!!!!!!!!! onda mu ja kazem nesto tipa "pa moras da dodas index da sql server ne bi sekvencijalno isao kroz celu tabelu i trazio rezultat" na sta me covek zabode stosom "there is a way other then reading the table sequentially?"

To je covek koji ima 10000GBP brutto MESECNO!!!!!!!!! i prodaje se kao PHP+MYSQL DEVELOPER!!!!!!!!!!!

 
Odgovor na temu

Tyler Durden
Tyler Durden
Beograd

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



+1365 Profil

icon Re: Optimizacija mySQL servera09.03.2009. u 16:01 - pre 183 meseci
U kojoj mjeri je moguće povećanjem RAM memorije sve vezano za MySQL "strpati" u sam RAM? Kako bi se naravno drastično poboljšale performanse. Naglasak na drastično.
Beneath civilization's fragile crust, cold chaos churns...
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.xdsl.beograd.com.

Sajt: mysql.rs


+2377 Profil

icon Re: Optimizacija mySQL servera09.03.2009. u 16:59 - pre 183 meseci
Citat:
Tyler Durden: U kojoj mjeri je moguće povećanjem RAM memorije sve vezano za MySQL "strpati" u sam RAM? Kako bi se naravno drastično poboljšale performanse. Naglasak na drastično.


"drasticno" je vrlo subjektivan pojam :)

samo ram u svakom slucaju nije dovoljan, posto, ako imas tabelu od 2M slogova, i cela tabela je u ram-u, i tabela nema indexe search na toj tabeli ce biti mnogo sporiji nego search na istoj toj tabeli koja je na disku a koja ima pravilno napravljene indexe ..

dakle, strpas sve u ram i ako nije dobro dizajnirana baza i dalje imas lose performanse (naravno mnogo bolje nego da je ta ista baza na disku, ali mnogo losije nego sto mozes da imas sa dobrim dizajnom).

sto se tice koristenja ram-a ...
- ako ima dovoljno ram-a stavljanje /tmp na ram disk (tmpfs) moze znacajno da ubrza upite koji koriste blobove posto takve temporary tabele uvek idu na disk, ako je taj disk u ram-u ubrzanje je nekoliko puta (drasticno)
- za innodb, innodb buffer je ultra bitan, sto vise rama mu dati to bolje, u slucaju da je innodb bafer veci od baze cela baza ce biti u ram-u (ucitace se prvom prilikom) - dakle ubrzanje u odnosu na "mali innodb buffer" je nekoliko puta ... evo covek koji je inicirao ovu pricu, bez ikakve promene upita i db modela (a mnooogo toga bi moglo da se promeni da se ubrza i do 20x) je upit ubrzao 40tak puta koliko sam svatio time sto je povecao innodb, drugi kolega ovde sa foruma je query koji se nije zavrsio posle 2 minuta prekinuo i kukao kako je mysql spor, onda je digao innodb buffer na 256M i dobio rezultat za 2 sekunde .. (to mu dodje preko 120x ubrzanje) ... i pritom, u svim ovim slucajevima je buffer bio manji od velicine tabele sa kojom se radilo i "mnogo manji" od velicine cele baze (bar u ovom drugom slucaju, za prvi nisam pitao koliko ima ram-a i koliko je velika baza) ..
- za myisam nije tako jednostavno .. on koristi fs cache .. tako da tu OS pomaze sa svojim kesiranjem ..

e sad ... razli baferi .. query_cache posebno mogu mnoooooogo da pomognu ako se koriste kako treba (sa hintovima i slicno) ... memcached (nema veze sa mysql-om ali se vrlo cesto koristi u kombinaciji) moze isto puno da pomogne .. no to je sad van direktnog pitanja ...

obrati paznju da je mysq cluster do 5.1 / 6.x imao sama "in memory data" ..tj na klasteru svi podaci su u memoriji ... to daje ogroman troughput ali opet sa druge strane zbog organizacije klastera (distribuiranih podataka) na visenodnom klasteru kopleksan join moze da bude bezobrazno spor .. (nema taj problem na 2node clusteru posto su svi podaci na jednom nodu)... no tu moze da se vidi benefit in memory baze, najveci problem koji imamo sa klasterom su lcp-ovi posto su i najbrzi diskovi suvise spori da povremeno snime lcp (nedo bog da se od njih zahteva da to non stop rade) ..


 
Odgovor na temu

mojeKorIme
BiH

Član broj: 59512
Poruke: 350
92.36.254.*



+1 Profil

icon Re: Optimizacija mySQL servera10.03.2009. u 06:56 - pre 183 meseci
hahhaha
@bogdane tvoje iskustvo i prisustvo na ovom forumu je neprocjenjivo! Ne znam odakle crpis energiju.. reci nam jos to pa nam ne treba vise nista ;)
Give me six hours to chop down a tree and I will spend the first four sharpening the axe.
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.xdsl.beograd.com.

Sajt: mysql.rs


+2377 Profil

icon Re: Optimizacija mySQL servera10.03.2009. u 12:46 - pre 183 meseci
Citat:
Ne znam odakle crpis energiju..


:D :D :D iz ovakvih komentara :D :D :D

sve se svodi na "give something back" ... ja vec duuuuuuuuuuugo vremena zivim jako lepo od open source-a ... sto tako sto sam ga koristio za projekte (mysql, pgsql, php, gcc, openldap, linux.... i mnogo projekata oko toga) tj u svojim projektima, posle tako sto sam "ovoj i onoj" firmi smanjio troskove drasticno i ubrzao proizvodnju tako sto sam ih prebacio na OS/FOSS .. pa sve do rada direktno za jedan FOSS projekat kakav je mysql ... 99% stvari koje znam sam naucio iz "ukradenih" tekstova sa foruma, gofera i sl. vreme je da nesto od toga vrnem nazad ...

nadam se da ces i ti, sutra, kada budes radio "samo jedan posao", budes imao malo slobodnog vrmena i malo vise znanja, resiti da to podelis sa drugima i "give something back" ...

no .. da se vrnemo na temu ...

mislim da je Durdenovo pitanje pomoglo da se pojasni cinjenica da je za MySQL jako bitno o kom se storage engine-u prica ... optimizacija za innodb nije ista kao optimizacija za myisam, falcon je opet posebna prica, maria posebna ... gomila drugih, sto free, sto proprietary storage engine-a koji postoje za mysql su opet zasebna prica ... dakle, odabir storage engine-a je jako bitan i utice na sve ...

ono sto mogu da kazem, a nije bas "javna informacija" .. (mada nije bas ni strogo cuvana tajna), je da kako trenutno imamo merlin koji skuplja i analizira gomilu podataka o serveru, vec imamo neke "ideje" oko automatskog setovanja servera .... u WL-u je da se u 6.1/6.2 stavi "auto config" gde je jedini info koji korisnik daje mysql-u "nemoj da trosis vise od XYZ G ram-a" a mysql sve ostalo konfigurise sam, realtime, u odnosu na statistike o koriscenju skupljenje tokom rada.... no .. ja ne ocekujem 6.0 ove godine tako da .. ima do toga vremena ..
 
Odgovor na temu

Schmidt
RHCE

Član broj: 80784
Poruke: 647
*.blic.net.



+10 Profil

icon Re: Optimizacija mySQL servera10.03.2009. u 13:22 - pre 183 meseci
Za ovog engleza sam tacno znao da ce biti do kljuca, jos dok sam citao vec sam se poceo smijati. Desavalo se i meni takvih stvari, ali koliko god da ih se desi uvijek me nasmiju i iznenade :)
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.xdsl.beograd.com.

Sajt: mysql.rs


+2377 Profil

icon Re: Optimizacija mySQL servera10.03.2009. u 13:31 - pre 183 meseci
Citat:
Schmidt: Za ovog engleza sam tacno znao da ce biti do kljuca, jos dok sam citao vec sam se poceo smijati. Desavalo se i meni takvih stvari, ali koliko god da ih se desi uvijek me nasmiju i iznenade :)


nije problem sto on nije stavio kljuc .. desava se i najboljima da nesto previde, da zablokira mozak, da ... ma necu ni da pocinjem sa mojim biserima ... poenta je da taj covek uopste ne zna sta je to index, on bazu zamislja kao sistem koji jako brzo cita txt fajlove i vadi podatke .. iliti sto bi nas svet reko "kako mali perica zamislja rdbms" - e taj covek ima toliku platu i na takvom je polozaju i smatraju ga "expertom" - to je ono sto boli ..
 
Odgovor na temu

[es] :: MySQL :: Optimizacija mySQL servera

Strane: 1 2

[ Pregleda: 12627 | Odgovora: 39 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.