El día 31 de agosto de 2010 13:52, Alejandro Gramajo <[email protected]> escribió: > Hola, > > tal cual dice Guido, sino tenes un buen hardware no aprovechas el > máximo de Percona. > No te va a consumir mas recursos que otro fork de MySQL. > > Para tu caso de conexiones concurrentes no vas a tener problemas con > usar el branch de MySQL 5.1.x, es mi recomendación. > > Ahora bien si algún día tu aplicación crece mucho, acá te dejo un > ejemplo de cosas que se pueden hacer: > > Tengo un par de clientes donde se usan MySQL 5.1 (tablas InnoDB y > MyISAM), se llegan a las 4000 queries por segundo (qps) de pico y el > hardware es 16gb ram, dual quad xeon ("8 threads") y tablas de > millones de registros. > > Realmente se notan las mejoras en InnoDB, los queries como UPDATE y > REPLACE lockean las base, ahi es donde XtraDB/InnoDB es mas > performante en ambientes multithread (con multiples micros y mucha > ram). > > Pero cuando estamos en estos números de qps no alcanza solo con > descansar tranquilo en eso, estas son algunas otras mejoras que se > pueden hacer: > > - lib de Malloc de Google, que es mejor que Malloc tradicional para > multithreading. > http://goog-perftools.sourceforge.net/doc/tcmalloc.html > - el patch de Percona de UserStatsV2 es muy bueno ya que te da > estadísticas adicionales > - Sphinx, para indexar búsquedas de texto (no usar MyIsam es lento > para muchos GB) > - Memcache, para cachear lo mas que puedas en ram y no preguntarle > mucho a la base > - MySQL slaves, distribuir los SELECT entre otros servers aliviana la > carga del Master, donde generalmente van los INSERT, UPDATE (tambien > podes tener un multi master, pero tenes que tener otros cuidados > especiales) > - optimización de código y revisar queries lentas (revisar con > EXPLAIN, hacer profiling) > - medir todos los parámetros de los servicios que necesites para tu aplicación > - sesiones en ram (tablas en ram, memcache u otros) > - sharding de los datos (dividir las tablas grandes por algún criterio) > - revisar tu my.cnf (leer ejemplo de my-huge.cnf) > - usar herramientas como mysqlreport y mysqlsla > - leer: High Performance MySQL (libro) > - leer: http://forge.mysql.com/wiki/Top10SQLPerformanceTips (es básico > pero ayuda) > - etc > > Después hay cosas de cada aplicación, en este caso no todas las tablas > son InnoDB ya que no es tan rápido como MyISAM pero claro perdés > seguridad porque no tenes transacciones (ganas velocidad). > > No usar count(*) en InnoDB ya que realiza una estimación y tarda, no > es como MyISAM que es exacto porque mantiene un indice especifico. > Luego InnoDB se fragmenta porque va dejando huecos de lo que borras > para acelerar el proceso insercion y borrado, por eso cada tanto es > conveniente volver a rearmar la base (en realidad si el espacio en > disco no es un problema no hay porque hacer esto) > > Bueno y así, hay muchas cosas a tener en cuenta, creo que ya me > extralimite con lo que vos preguntabas de Percona, pero creo que es > importante que sepas que no todo es responsabilidad de la base de > datos, mucha gente le pone el mega hardware pero sigue con problemas, > porque claro la aplicación tiene otros problemas o el cuello de > botella se encuentra en un lugar especifico. > > En mis casos, yo trato de usar el branch "oficial" 5.1.x con los > patches de Percona que me interesan. > > Saludos. > > -- > Alejandro > http://blog.baicom.com/ >
Che muy buena info, gracias. El sábado pasado se hizo una charla de Sphinx en Lanux. Saludos, -- Ariel Camino -- Para desuscribirte tenés que visitar la página https://listas.linux.org.ar/mailman/listinfo/lugar-gral/ Usuarios Software Libre Argentina (USLA)
