Estou recebendo muitos erros do apache que estou tendo problemas para rastrear. Eles estão em um sistema RHEL que executa um site Drupal de alto volume.
[Mon Sep 14 12:48:44 2009] [info] [client xx.xx.xxx.xx] (70007)The timeout specified has expired: core_output_filter: writing data to the network [Mon Sep 14 12:50:19 2009] [info] [client xx.xxx.xx.xx] (104)Connection reset by peer: core_output_filter: writing data to the network [Mon Sep 14 12:51:28 2009] [info] [client xx.xxx.xx.xx] (32)Broken pipe: core_output_filter: writing data to the network
Ocasionalmente (a cada 24 a 36 horas) haverá um pico de carga e o site não responderá totalmente. A média de carga aumenta de 1-1,5 para 200 normal. A maioria dos processos httpd que estão sendo executados será mostrada como 'D' - deadlocked - e a única maneira de fazer com que o servidor volte a ser "interativo" é para três. -finger-saudação ou aguarde até obter um prompt e killall -9 httpd .
Obviamente, o site não pode ser removido para que eu faça um monte de trabalho strace. Eu verifiquei a configuração do Apache e (novamente), tanto quanto eu posso dizer, EnableMMAP e EnableSendFile estão desativados. Os arquivos estão em uma montagem NFS v3, mas nem o servidor NFS, nem o servidor mysql, nem qualquer outra coisa, estão relatando erros. Nada apropriado no log do sistema ou no dmesg. O site também tem uma carga muito alta para reconciliar solicitações individuais com erros resultantes delas.
Neste ponto, estou pensando em erro de hardware de rede e prefiro colocar o site em uma segunda máquina. Alguém tem algum pensamento antes de eu fazer isso?
Conseguimos equilibrar o site mudando para o InnoDB e configurando o cache de chaves corretamente, além de adicionar um monte de memcache e outros. Todos os erros que citei acima foram aparentemente causados por clientes cancelando pedidos para processos de longa execução, porque assim que o banco de dados foi sintonizado, os erros desapareceram.
Esta é uma adivinhação radical, mas você já verificou quantas tabelas temporárias em disco o Drupal está criando?
Eu já vi isso causar problemas de carga (iowait).
mysqladmin -u root -p ext -ri 30 | grep Created_tmp_disk
A primeira execução informará quantas tabelas temporárias em disco foram criadas desde a última reinicialização do MySQL. Em seguida, ele lhe dirá quantos são criados na janela de tempo de 30 segundos (até que você controle-C fora dele).
A solução (band-aid) é colocar o tmpdir do MySQL em um sistema de arquivos baseado em RAM (por exemplo, tmpfs).
Acho que o que estou sugerindo é que isso inicia a cascata - e as mensagens que você está vendo são apenas conexões abandonadas.
Felicidades
Em suma, na sua configuração do apache, tente o seguinte:
AtivarMMAP desativado
Sendfile desativado
Em muito tempo:
Apache aparentemente mmapa arquivos e tenta usar o sendfile do linux ( link ) para performance quando está disponível, porém de acordo para os documentos do apache isso pode causar problemas de estabilidade nos sistemas de arquivos de rede se falhar ao ler o arquivo, veja:
Eles entram em algumas informações específicas sobre isso aqui:
Você pode encontrar informações sobre as diretivas EnableMMAP e EnableSendfile aqui:
adicione o nginx ao proxy do seu apache e forneça conteúdo estático diretamente. ou até mesmo, substitua o apache completamente. isso vai diminuir muito as cargas do apache.
Tags drupal apache-2.2