Luttant pour déboguer une utilisation élevée du processeur sur l'instance Amazon RDS MySQL

Nous exécutons un serveur MySQL RDS m1.xlarge et avons des problèmes avec une utilisation élevée du processeur. Il y a quelques semaines, nous avons eu des problèmes avec l'utilisation du processeur atteignant 100% sur une grande instance. Lorsque nous avons mis à niveau la taille à xlarge, cela a stabilisé les choses pendant un certain temps, mais l'utilisation du processeur a progressivement augmenté à nouveau.

Au cours de la dernière semaine, l'utilisation du processeur a atteint un sommet des années 90, atteignant 100% ou presque régulièrement hier, ce qui a mis notre site de production à l'arrêt. Après le redémarrage du serveur db, en quelques heures, l'utilisation du processeur est remontée aux mêmes niveaux.

J'ai exécuté show processlist sur le serveur mysql et surveille la même chose via l'administrateur MySQL. Il ne semble pas non plus y avoir de requêtes particulièrement longues ni de volume élevé de requêtes. Il y a quelques processus en sommeil depuis longtemps ... ce sont des démons de travailleurs isolés fonctionnant en dehors de notre application principale qui communiquent avec la base de données. J'ai copié dans la sortie de la liste de processus ci-dessous avec les noms de serveur modifiés pour donner une description de ce qu'ils sont:

+------+----------+---------------------------------------------------+--------------+---------+-------+--------------+----------------------------------------------------------------------------------------+
| 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 |
+------+----------+---------------------------------------------------+--------------+---------+-------+--------------+----------------------------------------------------------------------------------------+

Je dois également dire que le trafic sur le site est extrêmement faible pendant cette période, par rapport aux heures de pointe normales, environ 10% de la charge que nous voyons aux heures de pointe.

Nous avons également une nouvelle surveillance des reliques qui nous montre quels sont les appels de base de données d'application les plus longs. Cela nous montre qu'un appel particulier qui représente 99% du temps que notre application passe dans la base de données est une simple recherche par identifiant comme ceci:

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

(pas tout à fait la même chose que les requêtes en cours d'exécution dans la liste de processus ci-dessus)

Cette opération est devenue plus lente au cours de la dernière semaine environ, l'écart type entre les demandes de temps prenant augmentant, et le temps maximum nécessaire pour être mesuré en secondes. Je pense que c'est juste le résultat des problèmes d'utilisation du processeur plutôt qu'une cause.

Ce tableau compte environ 80 000 lignes, il n'est donc pas énorme. Il est prévu que la plupart du temps des applications dans la base de données soit consacrée à la recherche d'enregistrements dans ce tableau, la fonctionnalité principale de l'application est basée sur cela. J'ai moi-même exécuté une requête similaire à partir de mon serveur d'applications vers la base de données de production, tandis que l'utilisation du processeur reste autour de 100%, et elle répond en 1 ou 2 ms.

Sur la base de tout ce qui précède, nous ne savons pas comment procéder avec notre débogage. Je me demandais simplement si quelqu'un avait des idées sur le genre de choses qui pourraient être une cause profonde et comment enquêter sur celles-ci? L'accès au serveur sous-jacent exécutant notre serveur db est limité car il s'agit d'une instance Amazon RDS.

Géré pour résoudre ce problème, voici les étapes que j'ai suivies:

Tout d'abord, j'ai contacté l'équipe Amazon RDS en publiant sur leur forum de discussion, ils ont confirmé que c'était le processus mysqld qui occupait tout ce processeur - cela a éliminé un défaut de configuration avec autre chose en cours d'exécution sur le serveur physique

Deuxièmement, j'ai retrouvé la source des requêtes en cours d'exécution:

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

À l'origine, j'ai ignoré cela comme la cause, car aucune de ces requêtes ne semblait prendre particulièrement de temps lorsque je surveillais la sortie de show processlist. Après avoir épuisé d'autres avenues, j'ai décidé que cela valait la peine d'être suivi ... et je suis content de l'avoir fait.

Comme vous pouvez le voir dans la sortie de show processlist, ces requêtes provenaient d'un serveur d'utilité, qui exécute certains travaux utilitaires tactiques qui existent en dehors de notre code d'application principal. C'est pourquoi ils n'apparaissent pas comme lents ou causant des problèmes dans notre nouvelle surveillance des reliques, car le nouvel agent de reliques n'est installé que sur notre serveur d'applications principal.

En suivant ce guide de manière lâche:

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

J'ai pu retracer ces requêtes jusqu'à un processus en cours d'exécution spécifique sur notre boîtier de serveur utilitaire. Il s'agissait d'un peu de code rubis qui parcourait de manière très inefficace environ 70 000 enregistrements, vérifiant certaines valeurs de champ et les utilisant pour décider s'il devait créer un nouvel enregistrement dans «mytable». Après avoir fait une analyse que j'ai pu déterminer, le processus n'était plus nécessaire et pouvait donc être tué.

Quelque chose qui aggravait les choses, il semblait y avoir 6 instances de ce même processus en même temps en raison de la façon dont la tâche cron était configurée et du temps que chacune avait pris! J'ai tué ces processus et incroyablement, notre utilisation du processeur est tombée d'environ 100% à environ 5%!