Estou fazendo benchmarks de teste de carga HTTP (usando o Apache Benchmark e Siege ) em um pequeno aplicativo Java EE 1.7.0 / Tomcat 7.0.26 em execução no Debian Squeeze 6.0.4 x64 virtualizado com o VirtualBox 4.1 .8. O host do computador é o Ubuntu 11.10 x64.
Eu modifiquei esses parâmetros no Tomcat server.xml :
<Connector
port="8080"
protocol="HTTP/1.1"
connectionTimeout="200000"
redirectPort="8443"
acceptCount="2000"
maxThreads="150"
minSpareThreads="50" />
A aplicação executada no servidor demora cerca de 300 ms.
Este aplicativo está funcionando bem até uma certa quantidade de conexões simultâneas como essa:
ab -n 500 -c 150 http://xx.xx.xx.xx:8080/myapp/
ab -n 1000 -c 50 http://xx.xx.xx.xx:8080/myapp/
siege -b -c 100 -r 20 http://xx.xx.xx.xx:8080/myapp/
Um monte de socket connection timed out acontece e isso sobrecarrega completamente o processador host (mas a carga da CPU dentro da VM é normal).
Fazendo um htop no host, eu posso ver que o processador Virtualbox está rodando sob 300% da CPU e nunca desce mesmo depois que o teste de carga terminar . (Aloquei 4 processadores para a VM, se eu alocar apenas um processador, a carga da CPU ficará abaixo de 100%).
Reiniciar o Tomcat não faz nada, sou obrigado a reiniciar toda a VM.
Eu tentei lançar esses comandos ab / siege localmente na VM e tudo corre bem.
Primeiro, achei que estava relacionado a um limite de rede do Linux, conforme explicado aqui: Executar alguns benchmarks usando ab, e tomcat começa a realmente abrandar Então modifiquei esses parâmetros TCP:
echo 15 > /proc/sys/net/ipv4/tcp_fin_timeout
echo 30 > /proc/sys/net/ipv4/tcp_keepalive_intvl
echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle
echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse
parece ser melhor, mas continua a sobrecarregar a CPU do host e a saída socket connections time out em uma certa quantidade de conexões simultâneas.
Gostaria de saber se isso não está relacionado a como o Virtualbox lida com conexões externas simultâneas.
Eu já vi esse problema antes, quando você tem um loop que faz com que seu tráfego de rede seja reenviado para sempre. Tente verificar se você está recebendo uma quantidade de tráfego absurdamente alta em qualquer uma das suas interfaces de rede.
Se isso não funcionar, o uso da CPU é interrompido quando o sistema operacional convidado é interrompido ou você precisa desligar todo o contêiner da VM?
Primeiro de tudo você não diz nada sobre o host VBox. Quão poderoso é isso? Quando faço o teste de carga do VBox eu uso uma máquina com 12 núcleos e 32G de RAM para rodar um servidor virtual com 2 a 8 núcleos e até 12G de RAM. Em outras palavras, o host subjacente é mais poderoso do que o convidado do VBox, portanto estou razoavelmente seguro de que o convidado tem núcleos dedicados e RAM.
Em seguida, eu afino os sistemas operacionais host e guest para lidar com a carga. Coisas como o máximo de arquivos abertos, o máximo de soquetes abertos e várias configurações de TCP / IP, como buffers. Eles precisam ser configurados corretamente para fazer testes de carga. Se você representar graficamente seus dados com uma série de cargas, verá que, de repente, ficará muito pior quando atingir um limite de sistema operacional. Corrija isso antes de carregar o teste do seu aplicativo.
Você está testando de dentro da VM? Ou de outro lugar? Se a VM tentar apontar para 127.0.0.1, em vez disso, para o teste.
ab -n 500 -c 150 http://127.0.0.1:8080/myapp/