Estamos executando um servidor MySQL RDS m1.xlarge e tendo alguns problemas com o alto uso da CPU. Tivemos alguns problemas há algumas semanas, com a utilização da CPU atingindo 100% em uma instância grande. Quando atualizamos o tamanho para xlarge, isso estabilizou as coisas por um tempo, mas o uso da CPU aumentou gradualmente novamente.
Nas últimas semanas, a utilização da CPU estava nos anos 90, atingindo 100% ou aproximadamente de forma consistente ontem, o que interrompeu nosso local de produção. Após a reinicialização do servidor db, em poucas horas o uso da CPU voltou aos mesmos níveis.
Eu executei o show processlist no servidor mysql e tenho monitorado o mesmo através do administrador do MySQL. Também não parece haver consultas particularmente demoradas ou um alto volume de consultas. Há alguns processos em estado de suspensão por um longo tempo ... esses são daemons de trabalhadores isolados executando fora do nosso aplicativo principal que se comunicam com o banco de dados. Copiei na saída da lista de processos abaixo com os nomes dos servidores alterados para fornecer uma descrição do que são:
+------+----------+---------------------------------------------------+--------------+---------+-------+--------------+----------------------------------------------------------------------------------------+
| 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 |
+------+----------+---------------------------------------------------+--------------+---------+-------+--------------+----------------------------------------------------------------------------------------+Devo também dizer que o tráfego no site é extremamente baixo durante esse período, em relação ao horário normal de pico, cerca de 10% da carga que vemos nos horários de pico.
Também temos um novo monitoramento de relíquias, que nos mostra quais são as chamadas de banco de dados de aplicativos mais demoradas. Ele nos mostra que uma chamada específica que representa 99% do tempo que nosso aplicativo passa no banco de dados é uma consulta simples de busca por identificação como esta:
SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`id` = 123 LIMIT 1(não é o mesmo que as consultas em execução na lista de processos acima)
Essa operação ficou mais lenta na última semana, aproximadamente, com o desvio padrão entre solicitações de tempo aumentando, e também a quantidade máxima de tempo necessária para ser medida em termos de segundos. Eu acho que isso é apenas um resultado dos problemas de utilização da CPU e não uma causa.
Esta tabela possui cerca de 80.000 linhas, portanto não é enorme. Espera-se que a maior parte do tempo do aplicativo no banco de dados seja gasta procurando registros nesta tabela; a principal funcionalidade do aplicativo se baseia nisso. Eu mesmo executei uma consulta semelhante do meu servidor de aplicativos no banco de dados de produção algumas vezes, enquanto o uso da CPU permanece em torno de 100% e responde em 1 ou 2 ms.
Com base no que foi exposto acima, não temos certeza de como proceder com a depuração. Apenas me perguntei se alguém tinha alguma idéia de que tipo de coisas poderia ser uma causa raiz e como investigá-las. O acesso ao servidor subjacente executando nosso servidor db é limitado, pois é uma instância do Amazon RDS.
Respostas:
Gerenciado para resolver isso, estas são as etapas que segui:
Primeiramente, entrei em contato com a equipe do Amazon RDS postando em seu fórum de discussão, eles confirmaram que era o processo mysqld ocupando toda essa CPU - isso eliminava uma falha de configuração com outra coisa em execução no servidor físico
Em segundo lugar, localizei a fonte das consultas em execução:
Eu originalmente ignorei isso como a causa, porque nenhuma dessas consultas parecia levar um tempo particularmente longo quando eu monitorava a saída da lista de processos da mostra. Depois de esgotar outras avenidas, decidi que valeria a pena segui-lo .... e estou feliz por fazê-lo.
Como você pode ver na saída do show processlist, essas consultas eram provenientes de um servidor de utilidade, que executa alguns trabalhos de utilitário tático que existem fora do código principal do aplicativo. É por isso que eles não estavam aparecendo tão lentos ou causando problemas em nosso novo monitoramento de relíquias, porque o novo agente de relíquias está instalado apenas em nosso servidor de aplicativos principal.
Seguindo livremente este guia:
http://www.mysqlperformanceblog.com/2007/02/08/debugging-sleeping-connections-with-mysql/
Consegui rastrear essas consultas para um processo em execução específico em nossa caixa de servidores utilitários. Era um pouco de código ruby que iterava de maneira muito ineficiente por cerca de 70.000 registros, verificando alguns valores de campo e usando-os para decidir se era necessário criar um novo registro em 'mytable'. Depois de fazer algumas análises que pude determinar, o processo não era mais necessário e, portanto, poderia ser eliminado.
Algo que estava piorando as coisas, parecia haver 6 instâncias desse mesmo processo em execução ao mesmo tempo, devido à maneira como o trabalho cron foi configurado e quanto tempo cada um levou! Eu acabei com esses processos e incrivelmente o uso de nossa CPU caiu de cerca de 100% para cerca de 5%!
fonte