Minha instância do RDS está sendo inundada pela minha instância do EC2, mas minha instância do EC2 está funcionando perfeitamente

Question

Tenho uma configuração bastante complicada em meu console AWS.

1. Tenho uma instância EC2 na região A com LAMP instalado para o que chamarei de meu CRM.
2. Tenho um RDS na mesma região A do meu CRM que contém as informações dos pedidos/clientes que possuo.
3. Tenho uma instância EC2 em uma região B com LAMP instalado que chamarei de “Carrinho de compras”
4. Tenho um RDS na mesma região B com o banco de dados do meu carrinho de compras.
5. Detalhe um pouco menor (eu acho): tenho duas outras instâncias do EC2 nas regiões C e D com LAMP instalado que são "carrinhos de compras" secundários. Eles também têm suas próprias instâncias RDS.

Os dois servidores EC2 primários conectam-se um ao outro por meio de chamadas via CURL. Portanto, quando um pedido chega em meu servidor EC2 B, uma chamada curl é feita para meu servidor EC2 A para inserir o pedido, adicionar informações do cliente, etc. Além disso, meu servidor A pode fazer chamadas CURL para meu servidor B para atualizar preços, etc. O servidor B pode fazer chamadas CURL para o servidor A para obter os preços atuais de remessa para uma cidade.

Agora, o problema que estou tendo é que ontem, por volta das 4h, minha instância RDS B começou a inundar com conexões e ultrapassou o limite de 50 conexões simultâneas. Então atualizei de t2.small para t2.medium e agora tenho 90 conexões simultâneas, mas o problema persiste, chegando constantemente ao limite de 90 conexões em qualquer lugar a cada dois minutos até meia hora.

Também atualizei minha instância EC2 A, mas, novamente, isso não muda nada. Quando executo o seguinte em minha instância RDS B, normalmente obtenho de 6 a 10 threads, mas ocasionalmente começa a aumentar e, quando isso acontece, chega a 90 conexões normalmente em um ou dois minutos.

MOSTRAR status LIKE 'Threads_connected';

+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Threads_connected | 6     |
+-------------------+-------+
1 row in set (0.01 sec)

A execução do seguinte comando em minha instância RDS B mostra que está interrompendo conexões quando atinjo o limite de 90 conexões simultâneas:

mostrar status como 'Conn%';

+-----------------------------------+--------+
| Variable_name                     | Value  |
+-----------------------------------+--------+
| Connection_errors_accept          | 0      |
| Connection_errors_internal        | 0      |
| Connection_errors_max_connections | 6856   |
| Connection_errors_peer_address    | 0      |
| Connection_errors_select          | 0      |
| Connection_errors_tcpwrap         | 0      |
| Connections                       | 123258 |
+-----------------------------------+--------+
7 rows in set (0.03 sec)

Sempre que chego a 90 conexões no RDS B, minha instância do EC2 A fica lenta e as conexões aumentam na instância do RDS A. E minha instância EC2 B envia erros HTTP 500 porque a conexão mysqli falhou devido a muitas conexões.

Finalmente, se eu executar o seguinte em instâncias RDS A ou RDS B, vejogrande quantidadede comandos adormecidos, mas quase nunca qualquer consulta:

MOSTRAR PROCESSLISTA COMPLETO;

A "solução" temporária que encontrei é reiniciar o serviço Apache na instância EC2 A. Assim que eu fizer isso, todos os processos no RDS A e B serão resolvidos em alguns segundos.

Não entendo como isso pode começar a acontecer de repente e, mesmo depois de aumentar o poder das minhas instâncias, como isso pode continuar a acontecer. Estou sem ideias de onde procurar a seguir. O único "problema" que estou tendo, até onde sei, é que meu limite de conexões RDS está sendo atingido. As médias de carga do EC2 são muito boas (0,02 no momento). Não mudei nenhum código na última semana que consigo pensar.

Answer 1

Finalmente encontrei esse problema após cerca de 8 horas de pesquisa. Houve algum código nocivo introduzido em um dos meus sites por um freelancer que não conseguia fechar conexões mysql.

Espero que isso ajude alguém. Se você estiver enfrentando uma situação semelhante, verifique se há arquivos modificados recentemente no servidor com:

find . -type f -mtime -$n

Onde $né um número inteiro que representa o número de dias atrás em que você começou a ter problemas. Execute esse comando no diretório onde você espera que a alteração tenha ocorrido.