MySQL alto uso de CPU [cerrado]

191

Recientemente, mi CPU del servidor ha estado subiendo mucho.

Promedio de carga de la CPU 13.91 (1 min) 11.72 (5 min) 8.01 (15 min) y mi sitio solo ha tenido un ligero aumento en el tráfico.

¡Después de ejecutar un comando superior, vi que MySQL estaba usando 160% de CPU!

Recientemente he estado optimizando tablas y he cambiado a conexiones persistentes. ¿Podría esto estar causando que MySQL use grandes cantidades de CPU?

mysql cpu-usage Juzgando
fuente
44
Las conexiones persistentes casi siempre no son lo correcto.
Jason
¡Me los quitaré ahora y buscaré una diferencia porque nunca recuerdo que la CPU tuviera más de 2 hace un mes!
Juicio
2
Los servidores tienden a tener más de un núcleo. El porcentaje de uso de la CPU se calcula en relación con un núcleo, en otras palabras, un proceso que usa hasta dos núcleos por completo tendrá un uso de la CPU del 200%. Aquí, MySQL está utilizando hasta el 100% de un núcleo y el 60% de otro núcleo. Eso no significa que todas las CPU estén agotadas, lo más probable es que todavía tenga al menos dos CPU libres.
xaav
CPU alta casi siempre significa consultas ineficientes. Estos generalmente se resuelven mediante una mejor indexación (especialmente 'compuesta') y / o reformulando la consulta.
Rick James

Respuestas:

265

Primero, diría que probablemente desee desactivar las conexiones persistentes, ya que casi siempre hacen más daño que bien.

En segundo lugar, diría que desea verificar sus usuarios de MySQL, solo para asegurarse de que nadie pueda conectarse desde un servidor remoto. Esto también es una cosa importante de seguridad para verificar.

En tercer lugar, diría que desea activar el registro de consultas lentas de MySQL para controlar cualquier consulta que tarde mucho tiempo, y usarla para asegurarse de que no tiene ninguna consulta bloqueando tablas de claves durante demasiado tiempo.

Algunas otras cosas que puede verificar serían ejecutar la siguiente consulta mientras la carga de la CPU es alta:

SHOW PROCESSLIST;

Esto le mostrará cualquier consulta que se esté ejecutando actualmente o en la cola para ejecutarse, qué es la consulta y qué está haciendo (este comando truncará la consulta si es demasiado larga, puede usar SHOW FULL PROCESSLIST para ver el texto completo de la consulta) .

Usted también querrá mantener un ojo en cosas como el tamaño de buffer, caché de la tabla , caché de consultas y innodb_buffer_pool_size (si está utilizando tablas InnoDB) ya que todas estas asignaciones de memoria puede tener un efecto en el rendimiento de consulta que puede causar que MySQL comer CPU.

También es probable que desee leer lo siguiente ya que contienen buena información.

También es una muy buena idea usar un perfilador. Algo que puede activar cuando lo desee que le mostrará qué consultas está ejecutando su aplicación, si hay consultas duplicadas, cuánto tiempo están tardando, etc., etc. Un ejemplo de algo como esto es en lo que he estado trabajando llamado PHP Profiler pero hay muchos por ahí. Si está utilizando un software como Drupal, Joomla o Wordpress, querrá preguntar dentro de la comunidad, ya que probablemente hay módulos disponibles para ellos que le permiten obtener esta información sin necesidad de integrar nada manualmente.

Steven Surowiec
fuente
12
muchas gracias por esto, eliminé las conexiones persistentes y luego configuré el registro lento de consultas. ¡Leí el registro y la mayoría de las consultas provenían de dos tablas y las tablas no se habían indexado correctamente! solo han pasado unos 10 minutos, pero aquí está el resultado: promedios de carga de la CPU 0.48 (1 min) 0.95 (5 min) 2.42 (15 min) muchas gracias
Juicio
mismo problema, resuelto indexando las tablas que ralentizan el proceso, gracias Steven y Juddling
gabrielem
@Juddling ¿Podría explicar cómo indexar una tabla, por favor? Tal vez algún enlace? Sé que ha pasado un tiempo, pero soy realmente nuevo en esto. Perdón por la pregunta novata
JayVDiyk
Registrar las consultas lentas me ayudó a encontrar mi problema particular de la alta utilización de la CPU. En mi caso, era un complemento de Wordpress (ultimate-tag-cloud-widget) que estaba haciendo una consulta monstruosa con cada golpe solo para mostrar las etiquetas populares. Es un complemento excelente, pero debe mejorarse con algún tipo de almacenamiento en caché (terminé personalizándolo para resolver mi problema).
jkincali
Otra cosa que ayudó a un problema diferente fue modificar el parámetro innodb_buffer_pool_size mencionado anteriormente. Al intentar encontrar la causa de la alta utilización de la CPU, leí en alguna parte que innodb_buffer_pool_size debería tener al menos el tamaño del archivo ibdata1, que se encuentra en / var / lib / mysql. Parece que InnoDB funciona mucho más eficientemente cuando puede residir en la memoria. ¡Esto puede ser difícil de hacer en algunas situaciones porque ibdata1 puede ser enorme! También se sugirió en algún lugar para garantizar que innodb_log_buffer_size sea un 25% del tamaño de innodb_buffer_pool_size.
jkincali
167

Como esta es la publicación principal si buscas en Google para MySQL alto uso o carga de CPU, agregaré una respuesta adicional:

El 1 de julio de 2012, se agregó un segundo salto al tiempo UTC actual para compensar la lenta rotación de la tierra debido a las mareas. Al ejecutar ntp (o ntpd), este segundo se agrega al reloj de su computadora / servidor. A MySQLd no parece gustarle este segundo extra en algunos sistemas operativos, y produce una alta carga de CPU. La solución rápida es (como root):

$ /etc/init.d/ntpd stop
$ date -s "`date`"
$ /etc/init.d/ntpd start
RedPixel
fuente
22
Como la publicación original fue hace unos 3 años, dudo que sea la causa del problema del póster original. Pero fue la causa de mi problema, y ​​me salvó justo ahora, ¡así que gracias! Más información: blog.mozilla.org/it/2012/06/30/…
Russell G
55
El mismo problema y solución para mí en Ubuntu 12.04. Pasos para resolver un poco diferente: servicio ntp stop && date -s " date" && service ntp start El uso de CPU MySQL se redujo instantáneamente de 50 - 100% a 0 - 1%
David Laing
2
¿Se puede ejecutar esto solo para asegurarse? Quiero decir, ¿es seguro ejecutarlo incluso si no es la razón?
Muhammad Gelbana
2
1 de julio de 2015: acabo de experimentar este segundo error muy importante en un servidor AWS EC2 actual que ejecuta Amazon Linux. Usar sudo service ntpd stopen esta configuración.
Matt van Andel
1
+1 para esta solución. Mi MySQL estaba funcionando al 50-60% durante meses sin razón alguna, después de aplicar esta solución, ahora se redujo a un 0.0-0.3%, que era como se suponía. Muchas gracias.
Zeeshan
32

Si este servidor es visible para el mundo exterior, vale la pena verificar si tiene muchas solicitudes para conectarse desde el mundo exterior (es decir, personas que intentan entrar)

Rowland Shaw
fuente
1
No estoy seguro de por qué esto atrajo un voto negativo anónimo, dado que esto ha sido una causa en el pasado para algunos sistemas.
Rowland Shaw
2
Creo que el voto negativo es porque tener MySQL visible para el mundo exterior no es una buena idea.
MikeKulls
9
@MikeKulls No, no es una buena idea, ya que actuará como un objetivo para muchas personas para intentar ingresar, lo que dará una gran carga de CPU, de ahí mi respuesta como una posible razón.
Rowland Shaw
16
¡Odio cuando alguien simplemente baja el voto y se va!
Muhammad Gelbana
1
+1 porque esta es una razón absolutamente legítima para que MySQL tenga un uso elevado de la CPU, ¡y cualquiera para quien esta sea la respuesta realmente necesita esta información!
Chris Browne