Luchando para depurar el alto uso de CPU en la instancia de MySQL de Amazon RDS

Estamos ejecutando un servidor m1.xlarge MySQL RDS y tenemos algunos problemas con el uso elevado de la CPU. Tuvimos algunos problemas hace un par de semanas con la utilización de la CPU llegando al 100% en una instancia grande. Cuando mejoramos el tamaño a xlarge que estabilizó las cosas por un tiempo, pero el uso de la CPU se incrementó gradualmente nuevamente.

Durante la última semana, más o menos, la utilización de la CPU ha estado en los 90 altos, alcanzando el 100% o alrededor de forma consistente ayer, lo que detuvo nuestro sitio de producción. Después de reiniciar el servidor db, en cuestión de horas el uso de la CPU volvió a subir a los mismos niveles.

Ejecuté show processlist en el servidor mysql, y he estado monitoreando lo mismo a través del administrador MySQL. Parece que tampoco hay consultas particularmente largas o un gran volumen de consultas. Hay un par de procesos en reposo durante mucho tiempo ... estos son demonios de trabajadores aislados que se ejecutan fuera de nuestra aplicación principal y que se comunican con la base de datos. Copié en la salida de la lista de procesos a continuación con los nombres de los servidores cambiados para dar una descripción de lo que son:

+------+----------+---------------------------------------------------+--------------+---------+-------+--------------+----------------------------------------------------------------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+------+----------+---------------------------------------------------+--------------+---------+-------+--------------+----------------------------------------------------------------------------------------+
| 13 | rdsadmin | localhost:43513 | mysql | Sleep | 14 | | NULL |
| 15 | proddbuser | app-server-1.eu-west-1.compute.internal:36460 | proddb | Sleep | 46 | | NULL |
| 451 | proddbuser | app-server-1.eu-west-1.compute.internal:55512 | proddb | Sleep | 29 | | NULL |
| 912 | proddbuser | app-server-1.eu-west-1.compute.internal:45171 | proddb | Sleep | 13 | | NULL |
| 941 | proddbuser | app-server-1.eu-west-1.compute.internal:47353 | proddb | Sleep | 53 | | NULL |
| 951 | proddbuser | app-server-1.eu-west-1.compute.internal:48014 | proddb | Sleep | 37 | | NULL |
| 1009 | proddbuser | app-server-1.eu-west-1.compute.internal:51787 | proddb | Sleep | 36 | | NULL |
| 1041 | proddbuser | app-server-1.eu-west-1.compute.internal:53777 | proddb | Sleep | 14 | | NULL |
| 1572 | proddbuser | app-server-1.eu-west-1.compute.internal:42989 | proddb | Sleep | 3 | | NULL |
| 1592 | proddbuser | app-server-1.eu-west-1.compute.internal:43279 | proddb | Sleep | 162 | | NULL |
| 2909 | proddbuser | app-server-1.eu-west-1.compute.internal:37768 | proddb | Sleep | 35 | | NULL |
| 3028 | proddbuser | app-server-1.eu-west-1.compute.internal:42568 | proddb | Sleep | 5 | | NULL |
| 3119 | proddbuser | app-server-1.eu-west-1.compute.internal:46913 | proddb | Sleep | 76 | | NULL |
| 3189 | proddbuser | app-server-1.eu-west-1.compute.internal:51466 | proddb | Sleep | 5 | | NULL |
| 3216 | proddbuser | app-server-2.eu-west-1.compute.internal:44097 | proddb | Sleep | 14552 | | NULL |
| 3218 | proddbuser | app-server-2.eu-west-1.compute.internal:44099 | proddb | Sleep | 14552 | | NULL |
| 3219 | proddbuser | app-server-2.eu-west-1.compute.internal:44107 | proddb | Sleep | 44 | | NULL |
| 3220 | proddbuser | app-server-2.eu-west-1.compute.internal:44113 | proddb | Sleep | 26 | | NULL |
| 3223 | proddbuser | app-server-2.eu-west-1.compute.internal:44184 | proddb | Sleep | 50 | | NULL |
| 3224 | proddbuser | app-server-2.eu-west-1.compute.internal:44187 | proddb | Sleep | 1 | | NULL |
| 3226 | proddbuser | app-server-2.eu-west-1.compute.internal:44208 | proddb | Sleep | 33 | | NULL |
| 3229 | proddbuser | app-server-2.eu-west-1.compute.internal:44250 | proddb | Sleep | 14 | | NULL |
| 3232 | proddbuser | app-server-2.eu-west-1.compute.internal:44279 | proddb | Sleep | 26 | | NULL |
| 3233 | proddbuser | app-server-2.eu-west-1.compute.internal:44297 | proddb | Sleep | 31 | | NULL |
| 3237 | proddbuser | app-server-2.eu-west-1.compute.internal:44334 | proddb | Sleep | 27 | | NULL |
| 3239 | proddbuser | app-server-2.eu-west-1.compute.internal:44338 | proddb | Sleep | 11 | | NULL |
| 3241 | proddbuser | app-server-2.eu-west-1.compute.internal:44356 | proddb | Sleep | 26 | | NULL |
| 3260 | proddbuser | app-server-2.eu-west-1.compute.internal:44619 | proddb | Sleep | 8 | | NULL |
| 3337 | proddbuser | utility-server-1.eu-west-1.compute.internal:45193 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 309416 LIMIT 1 |
| 3419 | proddbuser | utility-server-1.eu-west-1.compute.internal:46136 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 284530 LIMIT 1 |
| 3463 | proddbuser | app-server-1.eu-west-1.compute.internal:59619 | proddb | Sleep | 9406 | | NULL |
| 3504 | proddbuser | utility-server-1.eu-west-1.compute.internal:47063 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 260571 LIMIT 1 |
| 3577 | proddbuser | app-server-1.eu-west-1.compute.internal:34394 | proddb | Sleep | 6734 | | NULL |
| 3585 | proddbuser | utility-server-1.eu-west-1.compute.internal:47990 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 231273 LIMIT 1 |
| 3664 | proddbuser | utility-server-1.eu-west-1.compute.internal:48909 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 201525 LIMIT 1 |
| 3716 | proddbuser | app-server-2.eu-west-1.compute.internal:56301 | proddb | Sleep | 27 | | NULL |
| 3748 | proddbuser | utility-server-1.eu-west-1.compute.internal:49850 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 167839 LIMIT 1 |
| 3771 | proddbuser | my-pc:30101 | NULL | Query | 0 | NULL | show processlist |
| 3831 | proddbuser | utility-server-1.eu-west-1.compute.internal:50785 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 123228 LIMIT 1 |
+------+----------+---------------------------------------------------+--------------+---------+-------+--------------+----------------------------------------------------------------------------------------+

También debería decir que el tráfico en el sitio es extremadamente bajo durante este período, en relación con las horas pico normales, alrededor del 10% de la carga que vemos en las horas pico.

También tenemos un nuevo monitoreo de reliquias que nos muestra cuáles son las llamadas a la base de datos de aplicaciones que requieren más tiempo. Nos muestra que una llamada en particular que representa el 99% del tiempo que nuestra aplicación pasa en la base de datos es una simple búsqueda por consulta de identificación como esta:

SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`id` = 123 LIMIT 1

(no es lo mismo que las consultas que se estaban ejecutando en la lista de procesos anterior)

Esta operación se ha vuelto más lenta durante la última semana más o menos, con la desviación estándar entre las solicitudes de tiempo que aumentan, y también la cantidad máxima de tiempo que se mide en términos de segundos. Creo que esto es solo el resultado de los problemas de utilización de la CPU y no una causa.

Esta tabla tiene alrededor de 80,000 filas, por lo que no es enorme. Se espera que la mayor parte del tiempo de las aplicaciones en la base de datos se pase buscando registros en esta tabla, la funcionalidad principal de la aplicación se basa en esto. He ejecutado una consulta similar desde mi servidor de aplicaciones a la base de datos de producción varias veces, mientras que el uso de la CPU se mantiene alrededor del 100% y responde en 1 o 2 ms.

Según todo lo anterior, no estamos seguros de cómo proceder con nuestra depuración. Me preguntaba si alguien tenía alguna idea de qué tipo de cosas podrían ser la causa raíz y cómo investigarlas. El acceso al servidor subyacente que ejecuta nuestro servidor db es limitado ya que es una instancia de Amazon RDS.

Gestionado para resolver esto, estos son los pasos que seguí:

En primer lugar, me puse en contacto con el equipo de Amazon RDS publicando en su foro de discusión, confirmaron que era el proceso de mysqld que ocupaba toda esta CPU; esto eliminó un error de configuración con algo más ejecutándose en el servidor físico

En segundo lugar, rastreé el origen de las consultas que se estaban ejecutando:

SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 231273 LIMIT 1 

Originalmente pasé por alto esto como la causa, porque ninguna de estas consultas parecía estar tomando mucho tiempo cuando supervisé el resultado de la lista de procesos de show. Después de agotar otras vías, decidí que valdría la pena seguir ... y me alegro de haberlo hecho.

Como puede ver en el resultado de show processlist, estas consultas provenían de un servidor de utlility, que ejecuta algunos trabajos de utilidad táctica que existen fuera de nuestro código de aplicación principal. Es por eso que no se mostraban tan lentos o causaban problemas en nuestra nueva supervisión de reliquias, porque el nuevo agente de reliquias solo se instala en nuestro servidor de aplicaciones principal.

Seguir libremente esta guía:

http://www.mysqlperformanceblog.com/2007/02/08/debugging-sleeping-connections-with-mysql/

Pude rastrear estas consultas a un proceso de ejecución específico en nuestra caja del servidor de utilidades. Esto era un poco de código ruby ​​que iteraba muy ineficientemente a través de alrededor de 70,000 registros, verificaba algunos valores de campo y los usaba para decidir si necesitaba crear un nuevo registro en 'mytable'. Después de hacer un análisis que pude determinar, el proceso ya no era necesario, por lo que podría ser eliminado.

Algo que empeoraba las cosas, parecía haber 6 instancias de este mismo proceso ejecutándose al mismo tiempo debido a la forma en que se configuró el trabajo cron y cuánto tiempo tomó cada uno. Eliminé estos procesos, ¡e increíblemente nuestro uso de CPU cayó de alrededor del 100% a alrededor del 5%!