O Apache está parado? / server-status mostra mais de 240 solicitações como “OPTIONS * HTTP / 1.0” 200 - “-” “Apache (conexão simulada interna)”

Question

Alguns detalhes:

• Servidor Web: Apache / 2.2.13 (FreeBSD) mod_ssl / 2.2.13 OpenSSL / 0.9.8e
• OS: FreeBSD 7.2-RELEASE
• Esta é uma prisão do FreeBSD.
• Eu acredito que eu uso o MPM do Apache 'prefork' (eu executo o padrão para o FreeBSD).
• Eu uso os valores padrão para MaxClients (256)

Eu habilitei mod_status, com "ExtendedStatus On". Quando vejo / status do servidor, vejo um punhado de solicitações regulares. Eu também vejo mais de 240 pedidos do 'localhost', como estes.

37-0    -   0/0/1   .   0.00    1510    0   0.0 0.00    0.00    127.0.0.2   www.example.gov OPTIONS * HTTP/1.0
38-0    -   0/0/1   .   0.00    1509    0   0.0 0.00    0.00    127.0.0.2   www.example.gov OPTIONS * HTTP/1.0
39-0    -   0/0/3   .   0.00    1482    0   0.0 0.00    0.00    127.0.0.2   www.example.gov OPTIONS * HTTP/1.0
40-0    -   0/0/6   .   0.00    1445    0   0.0 0.00    0.00    127.0.0.2   www.example.gov OPTIONS * HTTP/1.0

Eu também vejo cerca de 2417 solicitações ontem do host local, como estas:

Apr 14 11:16:40 192.168.16.127 httpd[431]: www.example.gov 127.0.0.2 - - [15/Apr/2010:11:16:40 -0700] "OPTIONS * HTTP/1.0" 200 - "-" "Apache (internal dummy connection)"

A página no link diz "Esses pedidos são perfeitamente normais e você, em geral, não precisa se preocupar com eles ", mas não tenho tanta certeza.

Por que existem mais de 230 deles? São essas conexões ativas? Se eu tiver "MaxClients 256" e mais de 230 dessas conexões, parece que meu servidor está perigosamente perto de ficar sem conexões disponíveis. Também parece que o Apache só precisa de um punhado dessas "conexões simuladas internas"

Na verdade, tivemos duas interrupções inexplicáveis na noite passada e estou me perguntando se essas "conexões simuladas internas" nos deixaram sem conexões disponíveis.

ATUALIZAÇÃO 2010/04/16

São 8 horas depois. A página / status do servidor ainda mostra que existem 243 linhas que dizem "www.example.gov OPTION *". Eu acredito que essas conexões não estão ativas. O servidor está praticamente ocioso (1 solicitações atualmente sendo processadas, 9 funcionários inativos). Existem apenas 18 processos httpd ativos no host Unix.

Se essas conexões não estiverem ativas, por que elas aparecem em / server-status? Eu esperava que eles expirassem alguns minutos depois de serem inicializados.

    

Answer 1

Bem, isso teve uma resposta surpresa. Isso foi causado por um problema no sistema de arquivos quando tiramos os instantâneos do sistema de arquivos UFS à meia-noite.

Isto parece ser causado por um bug UFS do FreeBSD. Nós usamos o FreeBSD Jails em um Host do FreeBSD, com o sistema de arquivos UFS padrão. O sistema de arquivos UFS é grande - 1,8 TB.

Uma vez por noite, executamos um backup usando 'dump (8)'. O dump (8) estava criando um snapshot do sistema de arquivos antes de fazer o backup, e isso congelou o sistema de arquivos. O despejo deve funcionar com sistemas de arquivos com menos de 2 TB, mas falhou no nosso caso. Esse cara teve o mesmo problema.

(Mudei minha resposta da seção de perguntas até aqui para a seção de respostas. stefan, 20100608)

    

Answer 2

Apache lida com um rebanho trovejante um pouco diferente do que você imagina. Quando você recebe um aumento do tráfego de entrada, ele gera vários processos-filhos, se determinar que precisa de mais, gera o dobro no próximo intervalo até que finalmente tenha processos suficientes para atender às solicitações ou atingir maxclients.

Se você vir isso, significa que o apache está apenas checando os filhos, e o que quer que tenha causado o apache a bifurcar muitos processos provavelmente já passou. Sim, eles ocupam conexões de clientes, mas, qualquer evento que tenha causado spool nas coisas provavelmente já passou.

A primeira coisa que eu verificaria em seus registros seria um monte de 302s antes do evento.

Se você tivesse algo como

<?php include("http://www.oursite.com/header.php");?>   

onde header.php estava faltando e

ErrorDocument 404 /404.php 

onde 404.php incluiu header.php, você obteria um loop recursivo e um hit nessa página imediatamente faria com que o apache usasse todas as conexões disponíveis.

    

Answer 3

Meu entendimento aqui é que, considerando que essas são conexões do pai ao processo infantil, elas são apenas o Apache que acompanha o que as crianças estão fazendo. Tenha em mente que:

• as crianças podem ficar por um bom tempo depois de processarem uma solicitação
• as conexões simuladas internas ocorrem regularmente
• se a criança não tiver feito mais nada (porque o servidor está ocioso), a conexão simulada será a mais recente processada

não é o caso, até onde eu sei, que as conexões fictícias "usem" as crianças. O Apache está verificando qual é o status de seus filhos, em vez de exercê-los para testar se eles funcionam ou não.

    

Answer 4

Se a memória funcionar, estas são conexões de teste geradas por proxies leves (como o Lighttpd) que ficam na frente de servidores mais pesados, como o Apache.

Como você está preso, o servidor host talvez esteja fazendo proxy de solicitações para o IP da cadeia (privada) via lighttpd?

    

Answer 5

Você precisa descobrir quais processos estão conectados à sua porta do Apache (suponho que seja 80).

Eu não tenho um sistema FreeBSD para que eu possa confirmar os comandos, mas pelo menos em um Mac isso deve lhe dar uma dica:

$ lsof -i

Ele mostrará algo como:

COMMAND     PID  USER   FD   TYPE    DEVICE SIZE/OFF NODE NAME
BadGuy    26655 yvesj   24u  IPv4 0x3f32270      0t0  TCP localhost:56696->localhost:56695 (ESTABLISHED)
GoodGuy 26656 yvesj   15u  IPv4 0x5b7666c      0t0  TCP localhost:56695 (LISTEN)
GoodGuy 26656 yvesj   16u  IPv4 0x72a9e64      0t0  TCP localhost:56695->localhost:56696 (ESTABLISHED)

A partir disso, você pode notar que o processo com o PID 26656 está escutando na porta 56695 e o processo 26655 está conectando a essa porta. Desta forma, você pode identificar quem é o cara mau (apenas não se confunda com a terceira linha, que mostra o outro lado da conexão (goodguy = > badguy).

Quando você aplicar isso ao seu caso, você encontrará quais outros processos em seu sistema estão mantendo essas conexões para sua instância do Apache.

Boa sorte!

Yves