Gestionar y optimizar servidor MySQL, barato, barato.

[Ñuño Martínez]

Sí, sé que es la taberna, pero es que creo que no entra del todo dentro del foro de bases de datos y tal.

Resulta que hace unos meses conocí a un chico que tiene una empresa de servicios web, y ayer me llamó porque tenían un problema de rendimiento con él. Acudió a mi porque necesitaban un "programador de bases de datos" (sic.) y sólo me conocían a mi, así que me pide presupuesto. Le digo que voy a revisarlo y que luego le cuento.

Pues eso, me da sus claves de acceso y tal, y como soy buena persona (suerte que tiene el tío) me limito a entrar, revisar logs (ni uno), el monitor y tal, y efectivamente: la UCP echando humo, la memoria por las nubes, los tiempos de consulta largos y extensos... y el monitor quejándose de que la caché es pequeña, que los accesos a disco son excesivos, que hay configuraciones contradictorias y que en caso de duda está usando el menor de los valores indicados. Total, que le contesto contándoles mi opinión, diciéndoles que yo tampoco soy tan experto como el creía y me abstengo a darles presupuesto, pero les digo que estoy a su disposición si no hay más remedio, que algo puedo hacer, y que consultaré a colegas de la profesión...

Y ahora sólo pido vuestra opinión, y si alguno sabe más que yo de MySQL que lo diga por si no encuentran nada mejor. Presupuesto han pedido, así que algo pagarán.

(Moderadores varios: si veis algo fuera de lugar, decidlo, no os cortéis. Incluso editadlo, si lo creéis oportuno)

[[AzidRain]]

El problema parece que no es el servidor (hardware y software) sino un mal diseño de la aplicación que lo utiliza. Lo que hay que ver en realidad es que consultas se lanzan y como están construidas así como las estructuras y tipos de las tablas, si utiliza transacciones (InnoDB) etc. Prueba revisando el servidor sin ninguna conexión activa y verás como los valores son normales, salvo que le hayan metido mano sin saber. Una consulta por muy lento que sea el hardware no debe tardar gran cosa a no ser que la aplicación se esté dando vida haciendo "select * " por todos lados aderezado con subquerys innecesarias, etc.

[rgstuamigo]

Hey Ñuño... ¿y será posible que tú nos puedas pasar las claves de acceso y demas cosas para ver nosotros mismo tambien?..
Saludos...

[mamcx]

Si puedes cambiar los SQL es un cosa. Si no es otra.

Si no puedes: Mas memoria, mejor disco. Ajustar el servidor a los parametros que te recomienda la tal herramienta o como digan en internet.

Si puedes, entonces te capturas los SQL que sean mas lentos, te traes un backup, miras el plan de consulta, corriges, mejoras hasta que sea optimo.

Y mira como se optimiza el Mysql en la documentacion. Y si estas en una version vieja, subirte a la mas nueva que puedas sin romper la app.

Y miras si hay que mejorar el linux.

Como vez, no hay como presupuestar esto porque NO SE SABE QUE PASA NI CUANTO VA A DEMORAR. Asi, que lo que yo haria, es cobrarles :

1- Por hora, si quieres que sea barato y hacerles el fa
2- Por generador de valor, si es un cliente serio (ie: Cobras no tanto por lo que te demores sino por lo valioso de tu trabajo, en base a la tipica historia del man que conecto un "cablesito" y cobro un millon de dolares)

[Ñuño Martínez]

Empezado por rgstuamigo

Hey Ñuño... ¿y será posible que tú nos puedas pasar las claves de acceso y demas cosas para ver nosotros mismo tambien?..
Saludos...

Eso me parece de lesa ética, apañero. No sé yo si sería corresto...

Empezado por AzidRain

El problema parece que no es el servidor (hardware y software) sino un mal diseño de la aplicación que lo utiliza. Lo que hay que ver en realidad es que consultas se lanzan y como están construidas así como las estructuras y tipos de las tablas, si utiliza transacciones (InnoDB) etc. Prueba revisando el servidor sin ninguna conexión activa y verás como los valores son normales, salvo que le hayan metido mano sin saber. Una consulta por muy lento que sea el hardware no debe tardar gran cosa a no ser que la aplicación se esté dando vida haciendo "select * " por todos lados aderezado con subquerys innecesarias, etc.

Empezado por mamcx

Si puedes cambiar los SQL es un cosa. Si no es otra.

Si no puedes: Mas memoria, mejor disco. Ajustar el servidor a los parametros que te recomienda la tal herramienta o como digan en internet.

Si puedes, entonces te capturas los SQL que sean mas lentos, te traes un backup, miras el plan de consulta, corriges, mejoras hasta que sea optimo.

Y mira como se optimiza el Mysql en la documentacion. Y si estas en una version vieja, subirte a la mas nueva que puedas sin romper la app.

Y miras si hay que mejorar el linux.

Como vez, no hay como presupuestar esto porque NO SE SABE QUE PASA NI CUANTO VA A DEMORAR. Asi, que lo que yo haria, es cobrarles :

1- Por hora, si quieres que sea barato y hacerles el fa
2- Por generador de valor, si es un cliente serio (ie: Cobras no tanto por lo que te demores sino por lo valioso de tu trabajo, en base a la tipica historia del man que conecto un "cablesito" y cobro un millon de dolares)

Pues lo primero que pensé nada más ver el percal se parece bastante a lo que habéis comentado, así que veo que sé más del tema de lo que pensaba. ¡Bien por mi!

Un problema es que es un sistema en producción, así que pararlo es complicado. En cuanto a lo de meterse dentro de la aplicación, están usando un programa de terceros; en concreto uno que permite montar un Facebook propio, imaginaos. Es más, me comentaron que ha tenido más éxito del esperado, así que supongo que parte del problema es ese éxito: la aplicación no está preparada para soportar la carga (no lo sé seguro pero apuesto a que está totalmente hecha en PHP), y posiblemente el servidor tampoco.

[mamcx]

Empezado por Ñuño Martínez

Un problema es que es un sistema en producción, así que pararlo es complicado.

Y quien ha dicho pararlo? Mas bien replicarlo. Copiar un backup y montarlo en otro servidor (ojala igualito). Se podria con cualquiera de los servicios en cloud y/o en una maquina virtual. El asunto es que si es un programa de terceros arreglarlo seria dificil/imposible dependendiendo si hay o no acceso al codigo fuente.

Empezado por Ñuño Martínez

la aplicación no está preparada para soportar la carga (no lo sé seguro pero apuesto a que está totalmente hecha en PHP), y posiblemente el servidor tampoco.

Aun sin tocar el codigo, hay mucho que se puede hacer:

1- Usar un CDN como https://www.cloudflare.com/ para acelerar el proceso de descarga del front-end. La parte de servir html/js/css es normalmenten la mayor culpable del la lentitud percibida por el usuario final.

2- Cambiar a nginx (si usan apache)

3- Hacer lo que dice (tanto como se pueda): http://developer.yahoo.com/performance/rules.html

4- Montar un cache en frente de la app web, como https://www.varnish-cache.org/

5 - Luego viene el servidor en si. Digamos que no teniendo de otra probaria de inmediato con https://www.digitalocean.com/ si el problema es acceso al disco (por lo del SSD) o si el problema es memoria mas ram. Si tienen acceso fisico al servidor, comprar ram y listo. Es BARATO: http://www.amazon.com/Corsair-Vengea...words=ram+64gb (o 32GB, o 24GB)


Nada de lo anterior requiere tocar codigo, y permite comprar tiempo. Ademas, son cosas "faciles" de hacer. Con excepcion de mover la BD a otro servidor, no hay downtime de nada (y aunque haya que moverlo, no es necesario parar del todo, es posible hacer el cambio sin downtime)

Luego viene la BD en si. Con ajustes a los parametros se puede mejorar MUCHO. Ademas, si la BD comparte equipo con el servidor web, moverlo a un equipo dedicado es MEJOR.

Luego lo que viene es poner un "puente" entre la BD y el servidor web. Como no se que motor es, es cualquier cosa parecida a postgress como este: http://wiki.postgresql.org/wiki/PgBouncer.

AUN NO SE HA TOCADO CODIGO.

A partir de aqui, no se me ocurre que hacer sin tocar codigo. Que sigue?

1- Usar redis/memcached para cachear cosas (como html, consultas) <- Posiblemente el mayor salto en desempeño aparte de subir la RAM
2- Mejorar los SQL
3- Particionar datos, BD con balanceo de cargas, etc.
4- Por ultimo, si realmente estan creciendo como espuma, contratar gente que sepa del cuento y reescribir la app, de forma progresiva.
Mucho de esto se aprende con http://highscalability.com/

[Ñuño Martínez]

Guau, Mamcx. Gracias por la guía.

Sé de buena tinta que el servidor está en una granja a la que no tienen acceso, así que eso de subir RAM y tal... pues no sé. Del resto, sé que tienen Linux, pero no estoy seguro de si se podrá acceder con un telnet. Lo que me pasaron fue una dirección web donde enlazas a distintas páginas que te dicen cosas (phpmyadmin y similares). Y sí, es MySQL, Apache... Vamos, un LAMP de lo más tópico.

Pero gracias. Le echo un vistazo a todo lo que me comentas, que aun no funcionando con esto puede funcionar con otras cosas.