Descobrir o que causa as conexões CLOSE_WAIT com Apache e PHP e Mysql

4

Primeiro, aqui está um pouco de contexto.

Nós temos uma aplicação PHP customizada que roda sob o Apache e que suporta nosso site.

Estamos atualmente com um alto tráfego em nosso site. Aqui está nossa configuração atual: - 10 servidores web linux por trás de um balanceador de carga (cada servidor tem 8 CPUs, 30Go RAM) - 1 servidor de banco de dados mysql linux (30 CPUs, 120 Go RAM)

O tráfego é mantido na maioria das vezes, mas às vezes por motivos inseguros, vemos um pico no total de conexões mysql ativas. Ele continua vazando até atingir o máximo e, em última análise, faz com que o aplicativo seja inutilizável por nossos usuários da web.

Quando isso acontece, em termos de média de carga, memória, uso da CPU, troca de disco, todos os servidores estão bem. Eles têm muitos recursos disponíveis.

Notamos que há muitos processos do Apache com um estado de conexão CLOSE_WAIT. Vimos aproximadamente 600 processos nesse estado em um de nossos servidores da Web.

Este parece ser um sintoma do problema que estamos encontrando. No entanto, estamos tendo dificuldades para cavar mais fundo. Aqui estão minhas perguntas:

  • Por que o Apache está ligado a esses processos?
  • Existem ferramentas ou técnicas de depuração que poderíamos usar para descobrir o que está causando isso?
  • Quais métricas devemos analisar para entender o que está acontecendo?

Obrigado pela sua ajuda antecipadamente,

    
por ssense 28.11.2013 / 17:11

1 resposta

5

Eu acho que você tem uma consulta que está bloqueando uma tabela / algumas linhas que outras conexões do mysql estão tentando atualizar por mais tempo do que deveria. Quando isso acontece, todas as solicitações de entrada se acumulam por trás dele até você atingir as conexões máximas.

O mesmo está acontecendo no lado do Apache devido a solicitações chegando e não tendo recebido uma resposta (devido a consultas sendo bloqueadas no banco de dados). O PHP tem uma conexão aberta com o banco de dados; ele fez uma consulta e ainda não recebeu uma resposta. Apache 'pendurado' nesse ponto é o que você esperaria que ele fizesse, já que está esperando por uma resposta.

O Apache parece estar suspenso do lado de fora (seu navegador / aplicativo móvel / etc) porque todas as crianças disponíveis em todos os seus servidores estão paradas aguardando uma resposta do banco de dados. Não há literalmente mais conexões disponíveis. (Isso também pode ser um limite de conexão definido no balanceador de carga). Se você ainda não estiver, inicie o registro de alterações de estado no seu balanceador de carga. Você provavelmente verá cada um dos seus servidores da web subindo e descendo repetidamente enquanto o problema do 'rebanho trovejante' (explicado depois) está ocorrendo.

Acredito que suas conexões em CLOSE_WAIT sejam um sintoma, não um problema. Eu não gastaria tempo tentando solucionar esse ângulo até ter cuidado dos problemas mais óbvios possíveis (banco de dados). As probabilidades são uma vez que você conserte que seu grande número de CLOSE_WAITs desaparecerá.

Para iniciar a solução de problemas no lado do banco de dados, ative o log de consultas lentas se você ainda não fez isso. Faça as solicitações de registro por mais de um segundo ou mais e veja o que aparece quando o problema ocorre.

Nota: O log de consultas lentas não registrará a consulta até que a consulta seja concluída. Não assuma que a primeira consulta aparecendo quando o problema é iniciado é a consulta do problema. Pode ou não ser.

Agora, você pode esperar que o site retorne ao normal quando a consulta problemática que bloqueia outras consultas terminar ...

Não é assim. Se você tiver 500 solicitações / s chegando regularmente e puder processar, digamos, 1000 solicitações por segundo e sua consulta bloquear o banco de dados por 10 segundos. Existem agora 5.000 solicitações sendo atendidas, além das 500 / s que ainda estão chegando. Isso é conhecido como o problema do Rebanho Trovejante .

Seu problema pode ser algo totalmente diferente, mas esses são exatamente os mesmos sintomas de um problema com o qual já lidei várias vezes e, na maioria desses casos, o problema era uma consulta de banco de dados bloqueando outras consultas. A única outra vez que me deparei com esse problema que não foi devido ao banco de dados foi no CentOS (o RHEL também tem o problema) 6. Infelizmente a Red Hat tem o artigo da base de conhecimento discutindo este problema disponível apenas para assinantes, mas há outras referências por aí, se você procurar por eles. Se você acha que pode ser esse o caso, é fácil de testar. Você simplesmente precisa adicionar uma única linha a seu resolv.conf .

Se o problema parece aparecer no mesmo / próximo à mesma hora do dia em que acontece você deve verificar seus cron jobs (ou qualquer outra coisa que esteja sendo executada em um cronograma definido) para ver se a consulta do problema está sendo enviada a partir disso.

Por fim, se você determinar que está sendo mordido pelo problema do rebanho, sugiro estabelecer limites no seu balanceador de carga. Você deve comparar um servidor para determinar aproximadamente o número máximo de solicitações que ele pode manipular simultaneamente e limitar o balanceador de carga a exceder esse número de conexões para cada servidor da web de backend.

Boa sorte.

    
por 28.11.2013 / 20:28