Citat:
after:
innodb_log_file_size
optimizacija mysql servera:
innodb_log_file_size – 256M do 1GB. Veca vrednost povecava performanse ali drasticno usporava “recovery time” tj. vreme koje je mysql-u potrebno da izvrsi “oporavak” innoDB table space-a posle “nasilnog” prekida rada. Ako koristite velike blobove, jako je bitno da ovaj parametar ima “vecu” vednost
Citat:
after:
query cache size je 128MB, ugasicu ga pa cu da uporedim po Bogdanovom savetu. Mada cu prvo da proucim sta to tacno radi, jer sam imao drugu sliku o ovom parametru pa sam malo zbunjen :).
Query cache pravi hash upita (Celog upita) i onda kesira rezultat. Kada ti napravis upit on opet napravi hash, proveri da li ima takav i ako ima vrati ti rezultat iz kesha, ako nema izvrsi upit, kesira ga i vrati ti rezultat. U meta od upita se nalazi od cega "zavisi" (baza, tabela ..)
Svaki put kada uradis update/delete/insert .. (neki data modifying statement) on mora da radi invalidatizaciju kesa i da brise sve upite koji imaju veze sa tim sto si ti promenio. Ta procedura je prilicno kompleksna.
- ako imas mnogo promena nad tabelama query cache moze da uspori stvari (posto ne stize da zadrzi upite dovoljno dugo da bi imao smisla i nekog ubrzanja a usporava update zbog invalidatizacije)
- bilo je par nezgodnoh bagova za qcache-om
Ja sam ti rekao da ubijes qcache skroz da bi bio siguran da nije do njega uglavnom zbog bagova... to je relativno nov deo mysql-a i nije bas naj-idealniji (dosta je bolji u 5.5 ali i dalje .. mozda je ostao jos neki bug)
Citat:
after:
Nema veze sa temom ali me interesuje kako da izbegnem ovo neslaganje i sta je svrha dve lokacije za error log. Da li da stavim istu putanju na oba mesta? Pretpostavljam da mozda iz nekog razloga (innodb?) mysql napravi neki safe shutdown/start i onda preuzme putanju error loga iz [mysql_safe] sekcije u my.cnf.
ili ostavi samo u [mysqld_safe] ili stavi isto
Citat:
after:
Nasao sam jos jedan od mogucih uzroka. Skripta koja radi svakodnevni backup lockuje celu bazu tokom bekapa tj. mysqldump ne ide kroz transakciju. Planiram da promenim to i da stavim --single-transaction opciju u dump. Doduse ima jedna tabela koja je MyISAM, pa cu mozda pored bekapa kompletne baze plus samo za tu myisam tabelu da radim poseban bekap sa lock tj. --opt opcijom. Za svaki slucaj, iako je tabela zanemarljivo mala :).
Nece ti to nista pomoci. Vidi da li mozes da iskoristis mylvmbackup (da li je sysadmin bio dovljno pametaj da turi datadir na lvm?), ako ne mozes, ubedi firmu da pljune pare MEB (mysql enterprise backup) - mozes da skines trial sa
https://edelivery.oracle.com/ .. to ti je najbrzi i najsigurniji nacin da napravis bekap
Citat:
after:
Inace, sam innodb tablespace je izlgeda prepun "smeca". Velicina je 2.5 puta veca od velicine innodb tabela i indexa. Tako da i to planiram da re-kreiram. Verovatno su ranije postojale jos neke innodb tabele/baze na serveru. Necu da grunem sve promene odjednom da bih imao kontrolu sta povecava performanse a sta ne ili cak pravi jos veci problem.
Dump -> Restore resava sve probleme :D. Ako to vec radis a datadir ti nije vec na LVM-u eto ga idealan trenutak da to promenis :) i onda ti mylvmbackup resava bekap problem
Citat:
after:
Planiram da za innodb flush method stavim O_DIRECT, samo ne znam da li to uopste ima smisla za virtuelnu masinu kao sto je slucaj i sa flush na hdd posle commit-a.
Bilo bi zanimljivo ako mozes da napravis neki test sa ovim ... obrati paznju isto da neki kerneli imaju problem sa ovim tako da .. mislim licno, ali ne znam sigurno, da neces dobiti nista sa o_direct
Za optimizaciju par hintova
1. prvo kada se ulogujes na mysql, radi to direktno iz konzole, preskoci raznorazne gui-e i ekipu
2. pre bilo cega kresni jedan SET SESSION query_cache_type = OFF; da budes siguran da te ne za... qcache
3. onda na tenane radi explain, select etc etc .. za svaki select radi SELECT SQL_NO_CACHE .. 3 puta za redom i gledan najgoru vrednost
4. 5.5, 5.5, 5.5, 5.5, 5.5 ... set profiling = 1 ...
http://dev.mysql.com/doc/refman/5.0/en/show-profiles.html ... imas profiling i u 5.0 ali 5.5 je toliko bolji :D