Reading time: 2 – 2 minutes
Aquesta última setmana he tingut alguns problemes de rendiment amb un servidor MySQL, de fet, hi havia en concret una taula que tenia fins a 53 milions de registres, malgrat el seu espai tampoc era tan gran al voltant de 4Gb l’accés de lectura i escriptura a la taula era molt lent, sobretot per funcions de filtrat una mica complexes.
Doncs bé, coses que he aprés que potser ús poden anar bé són:
- Cal habilitar les ‘slow_query_logs’ i tenir indexats tots els camps que apareixen després dels WHERE’s, això millora considerablement el rendiment.
- Cal incrementar el innodb_log_file_size fins a un 25% del valor del innodb_buffer_pool_size; això redueix considerablement el temps d’escriptura.
- Usar JFS, com a sistema de fitxers del directori ‘data’ del MySQL. És substancialment més ràpid que el ext3. Exemples de rendiment.
- Posar els logs en un disc dedicat, diferent del disc que té les dades.
- Usar el paràmetre ‘noatime’ en la partició que conté les de dades del MySQL.
- Deshabilitar la partició de SWAP, usar un ‘innodb buffer spool’ ben gran, sempre pensant amb la RAM disponible.
- Montar els directori temporal de MySQL sobre una partició RAM.
- Reduir el key_buffer size a 1-2Mb si no s’usen taules MyISAM.
- Usar el kernel 2.6 amb SMP amb processador multi-cos, és especialment important per aplicaions multithread com el MySQL.
- Usar RAID0 (stripped disks) i usar un servidor de replicació per les còpies de seguretat. Millora els temps d’I/O del disc, com és lògic.
7 thoughts on “Tuning d’un servidor MySQL”
Oriol, fa temps que no toco aquest tema a fons pero pel que respecte
al primer punt, tinc algunes anotacions que podries ser interessants.
Quan creem la taula és interessant indexar els camps tenin en compte
com es faran les cerces i és més important el com.
Per exemple si tenim una taula que sempre segueix un patró de cerca del tipus
select * from foo where ( a y )
Sera molt més optim indexar els dos camps a i b conjuntament, que no pas per
separats
Si tenim també un patró de ceca del tipus
select * from foo where ( a y )
Pero ja tenim un index del tipus a,b; crear un index amb només a sera redundant
De fet la meva recomanació es utilitzar la directiva EXPLAIN on es podra utilitzar
el selct per saber com far el mapping de claus tenin en compte el where.
Ups veig que m’ha polit els signes major i menor !!! les sentencies són
select * from foo where ( a _less_ x and b _greater_ y )
select * from foo where ( a _less_ x )
ostres, que interessant! gracies!
Hola, no acabo de entender porque
deshabilitar la partición de swap
afecta al rendimiento del mysql.
¿Algún sitio donde lo explican?
Gracias por el post
Santi.
Això es fa per evitar que la RAM s’acabi i es comenci a usar disc com a RAM, o sigui, SWAP això faria que el rendiment del MySQL baixés en picat!
Pensa que la diferència del temps d’accés a la RAM comparat amb el disc dur és abismal i per tant, usar SWAP és bona idea perquè un sistema no caigui però és mala idea perquè un sistema sigui òptim en rendiment.
Pero, ¿entonces que ocurre si el sistema se queda sin RAM?
¿el mysql se para?
¿el kernel empieza a matar procesos
para recuperarse?
Santi.
No vas malament, la qüesió és que es pot quedar fregit per manca de recursos. Les conseqüències exactes serien difícils de saber a priori.
El que has de fer és dimencionar bé els recursos i el sistema perquè això no passi mai. Que abans de passar això comencis a descartar feina.
També pots instal·lar un monit i quan els recursos es vagin acabant et pot avisar, o directament prendre accions més directes com tancar temporalment l’entrada de ‘packets’/feina o el que sigui per parar l’allau de feina.