Existem dois planos distintos de ataque para acompanhar ao diagnosticar esses tipos de erros:
Em primeiro lugar , existe o potencial de que é um problema relacionado ao software em uso: algo é essencialmente sugando conexões e não liberando-as de volta (seja em termos de thread, ou em um período de tempo razoável em termos de uma consulta lenta).
O log de consultas lentas é muito benéfico no diagnóstico de problemas, mas seu valor de 15 segundos é quase inútil: se uma consulta leva 15 segundos, o ponto final é muito complicado. Como regra geral, procuro por consultas que levem mais de um ou dois segundos para serem executadas. Trabalhe o que aparecer nesse log usando a palavra-chave EXPLAIN e observe o que está causando a lentidão (junções incorretas, classificação precisando de uma tabela temporária etc.) - alguma mágica inteligente com caches de consulta e índices pode ajudar se não for possível aprofundar e mexer no design de código / banco de dados.
Além disso, não negligencie o log de consulta geral no mysql. Embora você não queira deixá-lo ligado (por muito tempo) em um servidor de produção, ele pode dizer rapidamente se, em vez de uma única consulta ter uma certa idade, uma função específica no software é martelar o banco de dados com centenas de pequenas consultas. Obviamente, a única maneira de resolver esse tipo de problema é refatorando o código.
Em segundo lugar , você precisa investigar se a configuração do software é a culpa. Quantas conexões simultâneas você está experimentando? Qual é o número real de conexões máximas definidas no mysql? Pode ser algo tão simples como o apache está servindo digamos 100 solicitações simultâneas enquanto o mysql é configurado apenas para aceitar 20 conexões - obviamente algo vai dar. Se você puder avaliar a quantidade de tráfego que espera manipular, será necessário algum senso comum (e ocasionalmente uma pitada do Google para encontrar a configuração correta) para equilibrar todos os componentes.