Recientemente mi CPU de servidor ha estado yendo muy alto.MySQL alto uso de CPU
Promedio de carga de CPU 13.91 (1 min) 11.72 (5 mins) 8.01 (15 mins) 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 un 160% de CPU.
Recientemente he estado optimizando las tablas y he cambiado a las conexiones persistentes. ¿Podría esto causar que MySQL use grandes cantidades de CPU?
Primero te diría que probablemente quiera para desactivar las conexiones persistentes ya que casi siempre hacen más daño que bien.
En segundo lugar, diría que desea verificar dos veces a sus usuarios de MySQL, solo para asegurarse de que no sea posible que nadie se conecte desde un servidor remoto. Esto también es una cuestión de seguridad importante para verificar.
En tercer lugar, diría que desea activar el registro MySQL Slow Query para vigilar cualquier consulta que esté tardando mucho tiempo y utilizarla para asegurarse de que no haya ninguna consulta bloqueando las tablas de claves. largo.
Algunas otras cosas que usted puede comprobar serían para ejecutar la consulta siguiente, mientras que la carga de la CPU es alta:
SHOW PROCESSLIST;
Esto le mostrará las consultas que se están ejecutando actualmente o en la cola para funcionar, lo que la la consulta es y lo que 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 búfer, table cache, query cache 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 MySQL para comer CPU.
También es probable que desee darle una lectura a continuación, ya que contienen buena información.
Es también 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 tomando, etc. Un ejemplo de algo como este es en el 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 haya módulos disponibles que le permitan obtener esta información sin necesidad de integrar nada manualmente.
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! sólo han pasado unos 10 minutos, pero aquí está el resultado: promedios de carga CPU 0,48 (1 min) 0,95 (5 minutos) 2,42 (15 minutos) muchas gracias – Juddling
mismo problema, resuelto mediante la indexación de 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. Lo siento por la pregunta de noobish – JayVDiyk
Si este servidor es visible para el mundo exterior, vale la pena comprobar si se trata de tener un montón de peticiones de conexión con el mundo exterior (es decir, personas que intenta penetrar en ella)
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. –
Creo que el voto negativo es porque tener MySQL visible para el mundo exterior no es una buena idea. – MikeKulls
@MikeKulls No, no es una buena idea, ya que actuará como un objetivo para mucha gente para intentar ingresar, lo que dará una alta carga de CPU, de ahí mi respuesta como una posible razón. –
Como este es el puesto más alto si google para el uso de la CPU de alta MySQL o de carga, voy a añadir una respuesta adicional:
En el 1 de julio de 2012, un segundo salto se añadió a la actual UTC- tiempo para compensar la ralentización de la rotación de la tierra debido a las mareas.Al ejecutar ntp (o ntpd), este segundo se agregó al reloj de su computadora/servidor. A MySQLd no parece gustarle este segundo extra en algunos sistemas operativos, y ofrece una alta carga de CPU. La solución rápida es (como raíz):
$ /etc/init.d/ntpd stop
$ date -s "`date`"
$ /etc/init.d/ntpd start
Dado que la publicación original fue hace unos 3 años, dudo que sea la causa del problema original del póster. Pero fue la causa de mi problema, y me salvó hace un momento, ¡así que gracias! Más información: http://blog.mozilla.org/it/2012/06/30/mysql-and-the-leap-second-high-cpu-and-the-fix/ –
Mismo problema y solución para mí en Ubuntu 12.04. Pasos para resolver un poco diferente: service ntp stop && date -s "' date' "&& service ntp start El uso de la CPU MySQL disminuyó instantáneamente de 50 - 100% a 0 - 1% –
yup que lo hizo en Amazon's EC2 linux AMI también, simplemente cambie 'service ntpd stop/start' para las cosas init.d. –
Las conexiones persistentes son _almost_ always no lo correcto para usar. – jason
me los quitaré ahora y veré la diferencia porque nunca recuerdo que la CPU esté por encima de 2 hace un mes. – Juddling
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 utilice dos núcleos tendrá un uso de la CPU del 200%. Aquí, MySQL está usando 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