Administrace komentářů

Nedovolim si tvrdit ze to cele je zpusobene vadnou konfiguraci, nicmene ledacos se tim da dohnat. Nahazim par postrehu a treba neco z toho ti pomuze.

Zacal bych nekde 'pod' mysqlkem - pokud mas o hodne vic selectu nez updatu/insertu, tak je vyhodnejsi pouzit deadline elevator, nez treba v RHELu defaultni cfq. Rozhodne primountovat mysql storage s 'noatime' flagem. Mrkni co pise iostat/iotop, jestli opravdu v kritickych chvilich se ceka na disk a jestli to je spis pri cteni nebo zapisu.

Jako hodne informativni nastroj pro tweakovani parametru se mi osvedcil napriklad tuning primer ( http://www.day32.com/MySQL/tuning-primer.sh ). 'Hodne informativni' zminuju z toho duvodu, ze prave mysql moc nejde nastavovat zpusobem 'mam tam tolik a tolik a jsem spokojeny' protoze opravdu dost zalezi na povaze sql dotazu a vubec designu databazi/tabulek (spravne indexy, mnoztsvi joinovanych tabulek, pouzivani views, atd.). Napriklad tmp_table_size mi prijde pomerne dost vysoky, ale k tomu mas opravdu nizky max_heap_table_size, takze ta tmp tabulka se ti stejne nevytvori v pameti ( mysql opravdu prihlizi k oboum hodnotam a vybere si tu nizsi ). Query_cache_size bych osobne taky nastavil krapet vyssi, ale to takhle tezko soudit, protoze bych potreboval jeste vypis aktualnich hodnot counteru, aby bylo videt vyuziti qry cache, popr. jeji fragmentaci. Ale vetsinu z toho by ti mel napovedet ten tuning primer.

Jen tak pro zajimavost. Kolik prumerne mas tabulek na databazi? Kolik je tam databazi? Kolik mas nejvetsich tabulek a jaka je v prumeru jejich velikost?