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/
2010/8/31 <[email protected]>:
>> El 31/08/10 00:16, [email protected] escribió:
>>> Como bien dice Alejandro, necesitás hardware y una aplicación que lo
>>> aproveche.
>>>
>>> Yo migré hace poco a los builds de percona y noto una mejora mínima en
>>> la
>>> performance. Principalmente lo hice porque necesitaba un build de mysql
>>> mas actualizado que el que viene con mi distro, y percona me permitía
>>> tener mi NO bleeding edge distro con un mysql mucho mas nuevo.
>>>
>>> La versión nueva del mysql traía algunos errores graves resueltos de la
>>> 5.0 con los que venía sufriendo.
>>
>> Guido, Alejandro, muchas gracias por los datos.
>>
>> La aplicación con la cual lo estoy usando no hace uso de los features
>> que tiene InnoDB, sin embargo por política del cliente no se puede usar
>> una DB no transaccional.
>> Es por eso que estamos investigando alternativas y encontramos Percona.
>> Ahora, cuando dicen que "necesito hardware"... de cuanto fierro estamos
>> hablando? es decir, Percona consume muchos más recursos que un MySQL
>> estandar bajo las mismas condiciones de trabajo?
>>
>> Alejandro, vos comentás que la máxima ventaja se nota con miles de
>> conexiones por segundo... tu experiencia de cuantas miles es?
>>
>> Ahora no tengo los logs a mano (luego lo confirmo), pero si la memoria
>> no me falla, la aplicación, con cerca de 40 usuarios trabajando llegaba
>> a tirarle por momentos entre 400 y 700 queryes por segundo aprox a la
>> DB. Esto en el mediano plazo va a crecer y se esperan 200 usuarios
>> simultáneos en un par de meses.
>>
>> Abrazos, muchas gracias!
>> --
>
>
> Lo que yo quería decir, y estimo que Alejandro también, es que sino tenés
> power no aprovechás el build de percona. Para tener una pc con 2gb de ram,
> es lo mismo que uses el build oficial que el de percona. Lo aprovechás
> cuando tenés mucha ram para destinar al mysql. Ahí se empieza a notar la
> diferencia, que no es grande.
>
> Yo tengo un promedio de 1000 qps y va tranquilo con mis 8GB de ram y 2
> micros quad core una aplicación que usan centenas de usuarios.
>
> Pero tengo todo en innodb, y en estos días me parece que voy a triplicarle
> la ram.
>
> --
> Para desuscribirte tenés que visitar la página
> https://listas.linux.org.ar/mailman/listinfo/lugar-gral/
> Usuarios Software Libre Argentina (USLA)
>
--
Para desuscribirte tenés que visitar la página
https://listas.linux.org.ar/mailman/listinfo/lugar-gral/
Usuarios Software Libre Argentina (USLA)
