Olá Diogo.
Obrigado pela resposta. Aqui também usamos Apache+Plone. Eu acrescentei as
linhas, conforme disse e espero que resolva. O problema daqui deve ser o mesmo
que aconteceu aí. Como resolveram assim, acho que também teremos sucesso.
Mais uma vez, obrigado.
De: Diogo Tadeu Silva de Araujo dara...@certisign.com.br
Para: zope-pt@yahoogrupos.com.br
Enviadas: Sexta-feira, 12 de Dezembro de 2008 13:01:28
Assunto: Re: [zope-pt] Denial of Service - Plone x Cuil (Twiceler)
Oi Rodrigo,
A algum tempo atrás tivemos umas quedas inexplicáveis aos fins de semana (quase
todos os fins de semana) também aqui nos sites da empresa.
O estranho era que o tráfego cai 92% aos finais de semana, então não era nada
associado com consumo excessivo de banda por uso de milhares de conexões de
clientes.
Como usamos apache+plone, usando virtual hosts, só podia ou ser um bug no
apache, ou no plone. Apontei pro apache mesmo
Fui atrás do log do apache e vi coisas assim:
log
*
(70007)The timeout specified has expired: proxy: error reading status line
from remote server 127.0.0.1, referer:
http://www.google.com.br/search?hl=pt-BRq=fideliza%C3%A7aostart=30sa=N;
The timeout specified has expired: proxy: error reading status line from
remote server 127.0.0.1
proxy: Error reading from remote server returned by /
*
/log
A explicação ao pé da letra é que ao ocorrer este problema é por que 1 dos 3
itens abaixo ocorreu (variáveis de erros do Apache):
- Timeout na rede (lentidão de resposta na rede local) * Erro 70007;
- Conexão reiniciada pelo servidor Plone (serviço web) * Erro 104;
- Fim do arquivo encontrado, é repassado ao Apache um cabeçalho falso indicando
que a página chegou ao fim * Erro 70014;
Isto pode ocorrer por problemas na rede ou problemas no servidor de backend
(Plone) ou por causa da condição de race
(definição de prioridade) do código proxy.
Atualmente está condição de race disparada ao servidor backend (plone) pode
fechar a conexão corretamente
de um pacote que está em vôo (on the fly ou keepalive) depois que o serviço
httpd do Apache checa o estado
da conexão TCP e, começa a enviar requisições ao Plone, aguardando uma conexão
que já está morta.
Segundo as discussões no site do Apache, isso é um fato que deveria ocorrer
raramente e os browsers (ou robos) tentariam enviar novamente uma requisição a
página sem a interferência do Apache (tentativa de resposta sem consulta
prévia).
No fim das contas, o python ia a 100%, travava e caia... :-(((
Vimos então que não era só o Google ou Cuil que gerava isso, mas quase todos os
buscadores :-(
Fui atrás do problema e descobri que tratava-se de um bug do apache no modulo
proxy ( *mod_proxy* )
Este bug foi relatado aqui [1]:
bug
**mod_proxy: Trigger a retry by the client in the case we fail to read the
response line from the backend by closing the connection to the client.
PR 37770**
/bug
O *PR 37770* foi relatado aqui [2].
A solução sugerida era ou migrar para a versão 2.2.10 do Apache (versão atual),
onde o bug esta corrigido, ou colocar dois parametros no arquivo de
configuração do virtual host:
*Exemplo:*
#seusite.conf
NameVirtualHost seuip:80
VirtualHost seuip:80
* SetEnv force-proxy-request-1.0 1
SetEnv proxy-nokeepalive 1*
/VirtualHost
Mesmo migrando para a versão 2.2.10, o problema persistiu. Só depois de colocar
os parâmetros dentro do arquivo de configuração, o problema parou.
**
[1] : https://issues.apache.org/bugzilla/show_bug.cgi?id=37770
[2]: http://svn.apache.org/viewvc?view=revrevision=645813
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com