Alguns pedidos do Apache são lentos, mais completos instantaneamente

4

Eu tenho dois servidores web Dell R410 (2x quad core Xeon E5520 com 8gb ram) com o Debian 5 estável. Seu patch foi negligenciado por um tempo, então recentemente nós fizemos uma atualização para atualizar tudo - neccessitated por uma nova versão do aplicativo que executa o PHP 5.3.6. O kernel não foi atualizado porque veio do repositório backports da Debian (a versão instalada é 2.6.30-bpo.1-amd64).

Desde o patch, os usuários reclamam que o site está lento. A maioria das solicitações é veiculada instantaneamente, mas de vez em quando ela fica "paralisada" em uma solicitação. Não parece haver nenhum padrão discernível nas solicitações que ficam presas.

Esses servidores estão atrás de um balanceador de carga, eles foram atualizados ao mesmo tempo e ambos começaram a exibir esse problema no momento da execução do patch. Eles não foram reinicializados na época, mas foram sem efeito.

Eu configurei um script nos próprios servidores para fazer um loop sobre time curl localhost:80/alive , que tem um arquivo index.html simples contendo apenas "OK". Estranhamente, essas solicitações ainda são atrasadas com a mesma frequência e duração que as solicitações de conteúdo php real. Os tempos comuns são 3 segundos, 9s, 25s 45s e alguns são mais de 3 minutos. 45 segundos é um tempo de resposta comum, mas é claro que os navegadores desistem bem antes disso, então, efetivamente, não há resposta.

A configuração do trabalhador do apache é a seguinte:

<IfModule mpm_prefork_module>
    StartServers        50
    MinSpareServers     10
    MaxSpareServers     150
    ServerLimit         500
    MaxClients          500
    MaxRequestsPerChild   5000
</IfModule>

Parece-me sensato para um servidor com 8GB de RAM. Na prática, a contagem de funcionários raramente ultrapassa 170, portanto, não atingimos esse limite e há bastante memória livre. As médias de carga são baixas, elas pairam em torno de 0,5-1,5

O kernel é um backport antigo, então eu tentei atualizá-lo para o backport mais recente do lenny (2.6.32-bpo.5-amd64), mas ele entrou em pane com o boot e eu tive que fazer o nosso host reiniciá-lo com o antigo Eu gostaria de explorar outras opções antes de tentar atualizar seus bioses e formatá-los com o Debian 6.

O Apache parece ser um provável culpado, então o próximo passo é atualizar para o backport mais recente do apache, mas a versão foi um pouco menor, de 2.2.9-10 + lenny4 para 2.2.9-10 + lenny9, então Eu não esperava nenhuma mudança significativa.

O PHP está instalado, versão 5.3.6 do dotdeb. Versão anterior era 5.3.0 personalizado compilado. Além disso, meu chefe acabou de me informar que as solicitações por meio de https não são atrasadas, mas eu mesmo não confirmei isso.

# apache2 -V
Server version: Apache/2.2.9 (Debian)
Server built:   Dec 11 2010 21:34:00
Server's Module Magic Number: 20051115:15
Server loaded:  APR 1.2.12, APR-Util 1.2.12
Compiled using: APR 1.2.12, APR-Util 1.2.12
Architecture:   64-bit
Server MPM:     Prefork
  threaded:     no
    forked:     yes (variable process count)
Server compiled with....
 -D APACHE_MPM_DIR="server/mpm/prefork"
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_SYSVSEM_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D DYNAMIC_MODULE_LIMIT=128
 -D HTTPD_ROOT=""
 -D SUEXEC_BIN="/usr/lib/apache2/suexec"
 -D DEFAULT_PIDLOG="/var/run/apache2.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_LOCKFILE="/var/run/apache2/accept.lock"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="/etc/apache2/mime.types"
 -D SERVER_CONFIG_FILE="/etc/apache2/apache2.conf"

# apache2ctl -t -D DUMP_MODULES
Loaded Modules:
 core_module (static)
 log_config_module (static)
 logio_module (static)
 mpm_prefork_module (static)
 http_module (static)
 so_module (static)
 alias_module (shared)
 auth_basic_module (shared)
 authn_file_module (shared)
 authz_default_module (shared)
 authz_groupfile_module (shared)
 authz_host_module (shared)
 authz_user_module (shared)
 autoindex_module (shared)
 cgi_module (shared)
 deflate_module (shared)
 dir_module (shared)
 env_module (shared)
 geoip_module (shared)
 mime_module (shared)
 negotiation_module (shared)
 php5_module (shared)
 rewrite_module (shared)
 setenvif_module (shared)
 ssl_module (shared)
 status_module (shared)
Syntax OK

Qualquer ajuda muito apreciada!

    
por Alex Forbes 25.07.2011 / 19:51

1 resposta

8

Estou batendo com a minha contra a parede há uma semana, e meu chefe consertou isso.

Uma vez que observamos os tempos de resposta do Apache nos logs, percebemos que ele estava respondendo rapidamente - os atrasos estavam acontecendo antes mesmo de o pedido chegar ao Apache. Assim, ele olhou para as configurações da pilha tcp, comparando-as com outro servidor executando o Red Hat 5.6.

Para encurtar a história, permitir que os cookies syn do tcp ( net.ipv4.tcp_syncookies=1 em /etc/sysctl.conf) tenham resolvido o problema. Essa configuração foi projetada para proteger contra inundações de SYN e, aparentemente, permite respostas mais rápidas. É possível que estejamos inundados acidentalmente (ou deliberadamente).

Mais informações estão neste link, os sintomas descritos são exatamente o que estávamos vendo: -servers-running-linux.html "> link

Eu estava vendo netstat -alnt e a grande maioria das conexões estava no estado TIME_WAIT, não SYN_RECV (talvez a opção -l não mostre conexões semiabertas).

No entanto, estamos vendo isso no dmesg com frequência:

possible SYN flooding on port 80. Sending cookies.

Vou fazer mais algumas escavações.

    
por 26.07.2011 / 11:32