Las 11 de la noche… y creo que por fin he logrado estabilizar el problema, aunque bueno, ahora vienen las horas curiosas, así que quizás sea una noche larga (de estas de mucho café y tabaco…).
Como algunos ya sabéis, estamos dentro de un negocio que se basa mucho en las descargas masivas (estamos empezando y hablamos de 20mb/s sostenidos en muchas ocasiones). Hasta ahora me había encontrado con la necesidad de optimizar de una forma muy detallada el servidor Apache (me encuentro limitado a usar Apache, aunque existen mejores alternativas para optimizar la descarga); y esa optimización se basa en conseguir que aguante muchas conexiones sin morirse… básicamente.
Sin embargo, esta tarde me he encontrado con un grave problema que atañe al servidor (bueno, servidores…) MySQL. Estas descargas terminan normalmente en el envío de mensajes SMS, y por lo tanto, en querys de SQL para dar respuesta a dichos SMS. Tampoco puedo olvidar que en el momento de la descarga, también se ejecutan querys SQL… en fin, a lo importante, R.I.P.; si, no se me ha colado eso ahí, es que el daemon de MySQL ha muerto… o más bien, se ha quedado en un “lapsus” de dimensiones curiosas… dígamos como la cola del paro después de Navidad (o algo así debe ser…).
Lo facil era volver a levantarlo, lo dificil es que no se vuelva a caer. La optimización no es sencilla, hablamos de clustering de las bases de datos, de tablas que tienen más de 1 millon de registros por mes y en constante movimiento (algo así como un banco, en menor dimensión claro). Bueno, después de varias horas peleando con el maldito “my.cnf”, creo que he logrado encontrar un buen término medio entre las conexiones persistentes, la parametrización del caché, los tiempos de espera…).
¿Podré dormir hoy? No se sabe, todo se debate entre un servidor llamado “mire” y otro llamado “holandes”… y a todo esto… Apache sirviendo 189 peticiones simultaneas en este momento…



