Too many connections no MySQL: achar quem segura as conexões antes de subir o limite

O erro ERROR 1040 (HY000): Too many connections significa que o MySQL já tem o máximo de clientes conectados, definido em max_connections (151 por padrão no MySQL 8.4 e no MariaDB). Antes de subir esse número, veja quem ocupa as conexões: quase sempre é conexão parada em Sleep ou PHP-FPM com processo demais para o banco.

Como entrar no banco se ele recusa conexão?

O MySQL aceita uma conexão além do limite, reservada para conta com o privilégio CONNECTION_ADMIN (ou o antigo SUPER). Entre como root pelo terminal do servidor e rode:

SHOW GLOBAL STATUS WHERE Variable_name IN
  ('Threads_connected', 'Max_used_connections', 'Connection_errors_max_connections');

SELECT user, SUBSTRING_INDEX(host, ':', 1) AS origem, command,
       COUNT(*) AS conexoes, MAX(time) AS maior_tempo
FROM information_schema.processlist
GROUP BY user, origem, command
ORDER BY conexoes DESC;

O SUBSTRING_INDEX tira a porta do host, senão cada conexão TCP vira uma linha separada no agrupamento.

O que costuma ocupar as conexões?

  • Muitas linhas em Sleep com tempo alto: conexão aberta e esquecida. O wait_timeout padrão é de 28800 segundos (8 horas); em site PHP sem conexão persistente, eu uso alguns minutos.
  • Muitas linhas em Query do mesmo usuário: consulta lenta segurando o worker. Some o pm.max_children de todos os pools que falam com esse banco; se a soma passa do max_connections, o pico esbarra no erro 1040 antes de o PHP chegar ao limite dele.
  • Conexões de uma origem que você não reconhece: rotina de backup, painel de relatório ou o cron de outro sistema.

Como subir o limite sem criar outro problema?

SET GLOBAL wait_timeout = 300;
SET GLOBAL max_connections = 300;
SHOW VARIABLES LIKE 'open_files_limit';

O novo wait_timeout só vale para conexão aberta depois do comando. Grave os dois valores no arquivo de configuração do servidor (no Ubuntu, em /etc/mysql/mysql.conf.d/ ou /etc/mysql/mariadb.conf.d/), senão somem no restart. No MySQL 8.4, o limite efetivo é o menor entre max_connections e open_files_limit menos 810. E cada conexão reserva buffers próprios: dobrar o número sem olhar a RAM troca o erro 1040 pelo OOM killer.

Se travou nisso e precisa de ajuda, me chama aqui.

Dúvidas? Faça um comentário logo abaixo ou envie uma mensagem clicando aqui.

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *