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-BR&q=fideliza%C3%A7ao&start=30&sa=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=rev&revision=645813 Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com
