1. ¡OFERTA! con cupón "DIRVPS": hosting por $0,01 y también VPS Linux y Windows por $0,01 el primer mes por Interserver ← publi
    Descartar aviso
Descartar aviso
Al usar este sitio web, aceptas que nosotros y nuestros socios podamos establecer cookies para fines tales como personalizar el contenido y la publicidad. Más información.

MYSQL - Optimizar o Configurar ? ¿Que hace un sysadmin? Mysql 600% de cpu...

Tema en 'Asuntos Técnicos' iniciado por Skamasle, 19 Dic 2014.

  1. Skamasle

    Skamasle Usuario activo

    Pues eso, se que por aquí hay gente que sabe mucho y estaría bien una discusión sana sobre el asunto de mysql y que toca o no toca hacer cuando configuras uno.

    Cito a @neocomp que se que sabe mucho sobre el tema :D a ver que medidas toma el también, y claro ustedes que leen por aquí que supongo que más de uno se a encontrado casos así en algún servidor que de estos hay a patadas.

    ----

    El cliente te dice que el servidor va mal o la web no responde rápido y un largo etc

    Al entrar se ve algo como esto (casos reales)

    [​IMG]

    El mysql consume 600% de cpu

    He aquí el debate, el cliente dice que el servidor lo han revisado 3 sysadmins...

    ¿?

    Bueno el indicio es claro... hay my.cnf-bak* para aburrir, configuraciones de todo tipo, en el server mysqltuner, tunerprimer y un montón de herramientas para optimizar mysql.

    En los my.cnf de prueba y en el oficial aveces dejan cosas como:

    max_connections = 10000
    key_buffer_size = 4086M

    Luego vez el servidor y tiene solamente 4 gigas de ram y 2 cores o algo por el estilo,en este caso había más ram pero vamos es lo mismo, no se puede poner valores a lo loco ni teniendo 128 gigas de ram.

    Pero la pregunta que me hago es, si el consumo de mysql es de 600% y le metes max connections 10 000, el consumo no debería bajar a 100 si no debería subir a 800% ya que no tiene ningún sentido darle mas conexiones,, si cosas como el mysqltunner te dicen que el máximo de conexiones que a tenido es 50, en caso de tener 10 mil conexiones al mysql necesitaría un gran balanceador o cluster...

    En fin, locuras que hace la gente y que sysadmins no ven..

    Aunque no tengas idea de mysql si le has metido en la configuración todas las opciones posibles y el problema no se resuelve pueden pasar dos cosas.

    - 1 no has reiniciado mysql por eso no a tomado los cambios..:omgh
    - 2 no es problema de configuración. :banana:

    Esto pasa muchas veces, 3 sysadmin revisan el server, prueban 20 tipos de configuración distinta y luego resulta que el problema no es de configuración, aunque eso se ve venir a la primera si la web no tiene mucho tráfico y / o muchas consultas es complicado que consuma 600% de CPU, con retoques mínimos en la config debería bajar si es que fuera problema de config.

    En estos casos toca llamar a un programador para que revise las consultas o si sabes que hacer puedes mirarlo tu mismo.

    Aquí es donde se puede ver la diferencia entre configurar el mysql y optimizar lo que es la base de datos para un mayor rendimiento.

    Normalmente resolver estos problemas de consumo que no soluciona la configuración es sencillo otras veces es más complicado.

    En este caso una de las causantes del elevado consumo eran de selects que escaneaban 500 mil filas más o menos para mostrar el resultado.

    Lamentablemente no se que hice con la captura del select :omgh pero veré si pongo alguna abajo de otros casos similares.

    Luego de añadir unos cuantos indexes a varias consultas el resultado fue mejorando:

    [​IMG]

    El problema era lo mencionado arriba, selects que escaneaban 500 mil filas para mostrar resultados, luego de una hora de trabajo más o menos se optimizaron la mayoría de las consultas y quedo en un 18% de consumo de cpu y los grandes selects pasaron a escáner escasas 200 filas para mostrar el resultado, bajo la carga del servidor, la web comenzó a cargar rápido y todos los problemas resueltos, lo mejor de todo es que para reducir el consumo no se toco la configuración del mysql ( primero optimizar consultas, luego configurar si no es un caos y tiempo perdido )

    -----------

    Aquí encontré una consulta en un email de otro trabajo que andaba parecido el mysql con más de 400% de consumo, aunque en este caso todo el problema era de una sola consulta, luego había bajado a 2 % de consumo de cpu:

    select count(Id) from TB_LD_Campaigns where (Targeted_Mem_Types like "%\"Default\"%") and ((Targeted_Members_Gru="") and ((Targeted_coun="") or (Targeted_coun like "%ES%")) and ((Targeted_Languages="") or (Targeted_Languages like "%s%")) ) and (Id not in (select PTC_Id from TB_LD_Stats where MemberId=3196 and Event="eventosk" and New_Completion_Time_Interval is null)) and (Id not in (select PTC_Id from TB_LD_Stats where MemberId=3196 and Event="eventosk" and now()<Time + interval New_Completion_Time_Interval hour and New_Completion_Time_Interval is not null )) and (Suspended=0) and (Validity_Time_Start <= now()) and (Validity_Time_End > now()) and ((Impressions<Validity_Max_Impressions) or (Validity_Max_Impressions is null)) and ((eventosks<Validity_Max_eventosks) or (Validity_Max_eventosks is null));
    +----+--------------------+--------------------+------+---------------+------+---------+------+--------+-------------+
    | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
    +----+--------------------+--------------------+------+---------------+------+---------+------+--------+-------------+
    | 1 | PRIMARY | TB_LD_Campaigns | ALL | NULL | NULL | NULL | NULL | 16 | Using where |
    | 3 | DEPENDENT SUBQUERY | TB_LD_Stats | ALL | NULL | NULL | NULL | NULL | 533080 | Using where |

    Una sola consulta, 400% de cpu, y además de eso el mayor problema, la web cargaba 15 segundos más lento en algunos casos gracias a una sola query...

    En fin, cosas de programadores que a la larga tienen que resolver el que se encarga del servidor.

    ------------------------
    La pregunta es:
    ------------------------

    Ustedes como sysadmins que hacen en estos casos...

    - Hay algunos que cobran por configurar mysql pero luego solo configuran mysql y el problema sigue, o sea, como es problema de la web, no hacen nada mas.

    - Cambiar el presupuesto por que al no ser cosa de configuración hay que meter mano y ver que consultas causan problemas, revisar la base de datos entera y un largo etc para ver si lo pueden resolver o directamente pasarlo a un programador.

    - Pasarlo a un programador directamente si no ven que es problema de configuración.

    Lo fácil del asunto es que si es una sola consulta la que satura se detecta en seguida y se puede resolver en el momento casi siempre, por lo que no lleva mucho tiempo, pero cuando son bases de datos con cientas de tablas y hay consultas pesadas para muchas de ellas quita mucho tiempo :pensativo:


    ------------------

    Pues nada desahogado, por que me estoy bastante cansado que la gente meta mano a la configuración, cobre y se marche, solo poner unas lineas en la config, yo si veo un caso en el que la configuración no hace nada y las consultas son muy pesadas no cobro el trabajo, le digo al cliente que necesita decirle al que hizo la aplicación que optimice un poco esas consultas que matan al servidor.

    Algunos no lo entienden, no quieren pagar al programador por que les cobra muy caro... pero al final o es eso o un servidor más potente para mysql xD que aun así no mejorará la velocidad de la web mucho.
     
    A ideasmultiples, nonamef191118 y AMateos les gusta esto.
  2.  
  3. Hola Skam,

    Yo tiraría por la de - Pasarlo a un programador directamente si no ven que es problema de configuración.

    Un sysadmin no tiene por que lidiar con eso lo detectas y le dices al cliente que es problema de las consultas y que hay que contratar a uno.
     
  4. Estudiseno

    Estudiseno Usuario activo

    No se como haces siempre para hacer clientes...

    Si la solución es rápida se repara, si lleva horas de trabajo le paso otra factura... Al final no tienes que hacer tu lo que no han hecho otros cobrando..
     
    A justice13 y Skamasle les gusta esto.
  5. Skamasle

    Skamasle Usuario activo

  6. ideasmultiples

    ideasmultiples Usuario activo

    El 99% de las veces la optimización del MySql no sirve para casi nada, el origen del problema es un mal diseño de las DDBB, si alguien hace un selec con un par de JOIN en tablas de 100k de registros sin indexar correctamente, puedes optimizar, poner SSD, 32 procesadores o alquilar la computadora central del Enterprise....
    Para que un servidor de DDBB a tenga un buen rendimiento es necesario coger al diseñador de la DDBB de las orejas y enseñarle como debe de hacer los índices y si las DDBB a son auto creadas con RUBI o patatas parecidas, hay si llega el momento de cortarte las venas con una rebanada de pan Bimbo :omgh

    Así que antes de contratar a un optimizador de my.cnf analizar las consultas y hablar con el programador...
    :cool:
     
    A vicram y nonamef191118 les gusta esto.
  7. @Estudiseno un sysadmin no es un programador y no tiene por que saber php. Puede tener nociones pero no ha de saber php. Solo faltaría.
     
  8. Estudiseno

    Estudiseno Usuario activo

    Si sabes y puedes... ¿por que no ofrecer el servicio?
     
  9. Skamasle

    Skamasle Usuario activo

    PHP no pero si que tiene que saber perl o python por lo menos.
     
  10. jmginer

    jmginer Usuario activo

    @Skamasle En un servidor de alojamiento compartido "bien cargado", con "cientos" de webs, pongamos por ejemplo que se están ejecutando en total entre 300-500 querys por segundo.
    ¿Cómo haces para localizar la query que toca las narices?

    Gracias por la info!
     
  11. Skamasle

    Skamasle Usuario activo

    Es más delicado, pero si es constante el problema puedes hacer en tiempo real varios show processlist y ver que se esta ejecutando, es la forma más fácil y también activando el log slow queryes , ahí vez las queryes que tardan más, pero en hosting compartido y si el mysql esta cargado saldrán muchas.

    En todo caso con SHOW PROCESSLIST; y luego haces un explain podrás detectarlo y corregirlo.

    En compartidos en donde el mysql anda en 100% aun con muchas webs puede que solo una o dos webs estén jodiendo, lo malo es que al final afecta a todo el server.

    Si el server tiene cpanel puedes ver las queryes que se ejecutan desde WHM, aunque por ssh es más fácil, vez la query y luego la puedes ejecutar tu mismo y ver cuanto tarda y todo ese asunto.
     
    A jmginer le gusta esto.
  12. jmginer

    jmginer Usuario activo

    Gracias por la info!!!
     
  13. Con bash vas de sobra... no hace falta más.

    Salu2,
     
  14. cincinnati

    cincinnati Usuario activo

    Para un nivel 1 y quizás apurando para un nivel 2 con eso igual te vale, pero no vaya de sobrado. A partir de ahí sí te hace falta más. Mucho más. Ten en cuenta que cuanto más arriba sube la m i e r d a más tienes que saber y alguien tendrá que haber que limpie toda la m i e r d a que sube. Y lo digo con conocimiento de causa.
     
    nonamef191118, AMateos, Estudiseno y 2 otros les gusta esto.
  15. ideasmultiples

    ideasmultiples Usuario activo

    Un administrador que se precie tiene que saber, bash, php, perl, python, C, C++ y un par de cosas mas... :lol:
    :cool:
     
    A vicram y cincinnati les gusta esto.
  16. Bueno si no sabes programar siempre puedes tener a alguien y pagarle los scripts yo reconozco que para la programación soy un #### negado hasta para el php pero eso no quita que me administre un server. hay gente que no sabe programar y administra máquinas y los scripts los hace otro.
     
  17. ideasmultiples

    ideasmultiples Usuario activo

    Difícilmente puedes ser un buen administrador si no sabes programar...
     
    A vicram y Estudiseno les gusta esto.
  18. Bueno yo se de gente que no sabe programar y esta administrando y la programación la llevan otros con más experiencia.

    Puedes llevar la planeación de la instalación, el area de hacking etico y la optimización. Si funca mal las consultas la detectas llamas al programador oye te las apañas que esto es cosa tuya.
     
  19. ideasmultiples

    ideasmultiples Usuario activo

    Ferran, insistas lo que insistas, para ser un BUEN administrador necesitas saber programar, si estas en medio de un problema a las dos de la mañana no vas a encontrar a nadie a quien llamar.

    Un administrador no se dedica a "asegurar" se dedica a solucionar problemas...
     
    A Estudiseno le gusta esto.
  20. Llamo a un amigo de grado superior le digo que me programe lo que necesito le digo cuando me pides y me lo hace a cualquier hora. :)

    Me ahorro los dolores de programar el otro se come el marrón y yo le aseguro la máquina y la optimización.
     


Alojamiento web, Hosting Reseller, Servidores Dedicados - All in Hosting


    
    
    
    
Blog · Sitios amigos: GuiaHosting · Unidominios · Interalta ·