Optimizar MySQL, tuning que llaman...
Ratio: 5 / 5
El archivo de configuración por defecto que viene al instalar MySQL es el mismo desde hace ya varios años (¬¬') sin embargo el hardware ha cambiado, y mucho.
Nosotros tenemos algunos parámetros como estos y la verdad se nota, ya ha pasado una semana desde que empecé este estudio en esta máquina.
# para equipos con 2 o 3 GB de ram
key_buffer = 512M
max_allowed_packet = 2M
thread_stack = 128K
thread_cache_size = 16
sort_buffer_size = 2M
read_buffer_size = 2M
myisam_sort_buffer_size = 64M
thread_cache = 16
myisam-recover = BACKUP
#max_connections = 100
table_cache = 512
thread_concurrency = 8
query_cache_limit = 4M
query_cache_size = 256M
log_slow_queries = /var/log/mysql/mysql-slow.log
long_query_time = 3
No voy a explicar cada parámetro, por no hacer esto un tostón, pásate por la web oficial de MySQL aquí.
Como podéis ver cacheamos y mucho. Además le hemos dedicado un buen espacio de la RAM.
Esto es debido a nuestro uso, en pocas palabras no se trata de un servidor con miles de consultas por segundo, en cuyo caso dedicar tanta cache sería una locura. Se trata de un servidor con unas 50 bases de datos y algunas de ellas con varias tablas de 50.000 registros cada una, varias.
Esto hace que nuestras consultas sean pesadas, cuando teníamos 1M para la cache estas consultas de búsqueda pesadas no cabían en memoria y el servidor alcazaba un 300% de CPU tardando en responde lo suficiente como para hacer un timeout.
Durante estos picos de uso las otras bases de datos y webs de este servidor funcionaban, lentas, pero funcionaban. Ojo con esto, por que nos hace pensar cuantos servidores mal configurados funcionan con estos picos.
Veamos estas dos gráficas, la de arriba es la carga del procesador y la de abajo el uso de la memoria:
Como puede deducirse la línea AZUL es la carga total del sistema y la AMARILLA es MySQL.
A las 9 de la mañana se lanzaron consultas que hicieron que el procesador alcanzase el 300% de CPU, y la línea azul se salió de los gráficos durante varios minutos. Sin embargo como podemos ver en la gráfica inferior no se estaba usando RAM! Más de dos GB libres y el sistema no la usa! Ahora es cuando digo: MySQL caca!
A las 10 de la mañana ya habíamos afinado todo esto y podemos ver como calló temporalmente el uso de memoria de MySQL para ir llenándose poco a poco y no volver a hacer que la CPU se saturase. Incrementamos en 256Mb más el uso de memoria y la CPU no volvió a sobrepasar límites.
La conclusión deducida es que para consultas grandes MySQL no tira de RAM, cuando debería, y así mismo debe repartir los procesos de calculo.
Para nuestros servidores y el tipo de uso que se les da consideramos importante reservar el uso de RAM ya que no tenemos millones de demandas ligeras, si no centenares de peso a la vez.
Y para finalizar una pequeña anotación, si la base de datos que estás usando es tuya o tienes acceso a modificarla, por favor, aprovechate de los índices de MySQL, estos aunque hacen que consumas un poco más de memoria pueden reducir varios segundos, si segundos, los tiempos de respuesta en búsquedas!
