Executando alguns benchmarks usando ab, e o tomcat começa a realmente desacelerar

Question

Estou executando alguns benchmarks usando o banco de dados apache para um aplicativo java que está sendo executado no tomcat.

Digamos que eu faça um teste como:

ab -c 10 -n 10000 http://localhost:8080/hello/world

Ele vai rodar bem. Se eu seguir com:

ab -c 50 -n 50000 http://localhost:8080/hello/world

Mais uma vez, tudo correrá bem, mas se eu tentar de novo, ele começa a desacelerar após talvez 3.500 pedidos concluídos.

Preciso de ajuda para tentar depurar a causa raiz disso.

Eu corri no topo e tenho alguns shows de memória que não são usados, então a memória não parece ser o problema.

O processo tomcat6 vai para 70-80 ou até 107%.

Parece que reiniciar o tomcat resolve o problema, mas às vezes é necessária uma reinicialização do servidor.

Isto está em uma instalação padrão do tomcat que tem 200 threads alocados a ele.

Os logs do Tomcat estão vazios.

Atualizar

Então eu mudei ambos tcp_tw_recycle / reuse para 1, e executar o netstat mostra uma contagem muito baixa agora.

Antes de mudar o tcp_tw_recycle / reuse, notei que as coisas estavam ficando lentas e rodando o netstat e eu tinha 32400 tcp de conexões TIME_WAIT.

Portanto, uma atualização sobre a execução dos benchmarks agora, com o switch -k, estou vendo MUITO mais throughput. MAS, em algum momento, as coisas começam a desacelerar novamente, mas reiniciar o tomcat agora traz as coisas de volta ao normal. Antes, mesmo se eu reiniciei o tomcat, os tempos de resposta rodando ab seriam muito muito lentos. Agora, depois de alterar o tcp_tw_recycle / reuse, a reinicialização do tomcat volta ao normal. Running top mostra o tomcat com apenas 20% de cpu, então parece que o problema é com o tomcat agora, mas como posso descobrir o que?

    

Answer 1

Pode haver algumas coisas acontecendo aqui. Seu comando acima se traduz em 50 conexões simultâneas, cada uma emitindo 1000 solicitações. Uma coisa a notar aqui é que, se bem me lembro, o apachebench não permite manter ativo por padrão. Pode valer a pena adicionar isto (passe -k para o seu comando acima). Isso será mais um teste do mundo real de qualquer maneira, já que a maioria dos agentes usa o keep-alive, assim como o Tomcat, por padrão. Isso deve ajudar o problema se minhas teorias abaixo estiverem corretas.

1) Eu suspeito que o seu bater esse pool de discussão com muitos pedidos, uma vez que cada um está derrubando. Este é um grande sucesso para esses segmentos, bem como a pilha TCP / IP no sistema. O que me leva a ...

2) Você pode estar (ok, provavelmente está) ficando sem portas efêmeras ou atingindo soquetes TIME_WAIT. Se cada solicitação for realmente uma solicitação nova e exclusiva, é muito provável que você esteja correndo para uma situação TIME_WAIT com milhares de sockets nesse estado (dê uma olhada no netstat -an | grep -ic TIME_WAIT para uma contagem deles durante sua carga). Esses soquetes não poderão ser reutilizados, a menos que você tenha ativado o recurso time_wait_reuse no seu sistema. O fato de você estar usando o host local só piora isso.

Para mais informações sobre como reutilizar o time_wait, dê uma olhada aqui . Observe também que este thread corretamente aponta que a configuração do tempo limite fin_wait está incorreta no contexto de time_wait, portanto evite isso. Cócegas fin_wait no contexto de TIME_WAIT está errado e não irá ajudá-lo.

Portanto, dê uma olhada e ajuste o tcp_tw_recycle / reuse especificamente. Estes irão ajudá-lo a passar por seus testes, assim como manter-se vivo.