A taxa na qual meu servidor pode aceitar () novas conexões TCP de entrada é muito ruim no Xen. O mesmo teste em hardware bare metal mostra 3-5x acelerações.
- Por que isso é tão ruim sob o Xen?
- Você pode ajustar o Xen para melhorar o desempenho de novas conexões TCP?
- Existem outras plataformas de virtualização mais adequadas para esse tipo de caso de uso?
fundo
Ultimamente, tenho pesquisado alguns gargalos de desempenho de um servidor Java desenvolvido internamente, executando o Xen. O servidor fala HTTP e atende chamadas simples de conexão / solicitação / resposta / desconexão TCP.
Porém, mesmo ao enviar cargas de tráfego para o servidor, ele não pode aceitar mais do que ~ 7000 conexões TCP por segundo (em uma instância do EC2 de 8 núcleos, c1.xlarge executando o Xen). Durante o teste, o servidor também exibe um comportamento estranho, onde um núcleo (não necessariamente a CPU 0) fica muito carregado> 80%, enquanto os outros núcleos permanecem quase inativos. Isso me leva a pensar que o problema está relacionado ao kernel / virtualização subjacente.
Ao testar o mesmo cenário em uma plataforma não virtualizada bare metal, recebo resultados de testes mostrando taxas de aceitação de TCP () além de 35.000 / segundo. Isso em uma máquina Core i5 de 4 núcleos executando o Ubuntu com todos os núcleos quase totalmente saturados. Para mim, esse tipo de figura parece certa.
Na instância do Xen, tentei ativar / ajustar quase todas as configurações existentes no sysctl.conf. Incluindo a habilitação da Direção de recebimento de pacotes e Direção de fluxo de recebimento e fixação de threads / processos nas CPUs, mas sem ganhos aparentes.
Eu sei que o desempenho degradado é esperado ao executar virtualizado. Mas a este grau? Um servidor bare metal mais lento que o desempenho superior. 8-core por um fator de 5?
- Esse é realmente o comportamento esperado do Xen?
- Você pode ajustar o Xen para melhorar o desempenho de novas conexões TCP?
- Existem outras plataformas de virtualização mais adequadas para esse tipo de caso de uso?
Reproduzindo esse comportamento
Ao investigar mais sobre isso e identificar o problema, descobri que a ferramenta de teste de desempenho do netperf poderia simular o cenário semelhante que estou enfrentando. Usando o teste TCP_CRR do netperf, coletei vários relatórios de diferentes servidores (virtualizados e não virtuais). Se você deseja contribuir com algumas descobertas ou consultar meus relatórios atuais, consulte https://gist.github.com/985475
Como sei que esse problema não se deve a um software mal escrito?
- O servidor foi testado em hardware bare metal e quase satura todos os núcleos disponíveis.
- Ao usar conexões TCP keep-alive, o problema desaparece.
Por que isso é importante?
Na ESN (meu empregador), sou o líder do projeto do Beaconpush , um servidor Comet / Web Socket escrito em Java. Embora seja de alto desempenho e possa saturar quase toda a largura de banda fornecida em condições ideais, ainda é limitado à rapidez com que novas conexões TCP podem ser feitas. Ou seja, se você tem uma grande rotatividade de usuários onde os usuários vão e vêm com muita frequência, muitas conexões TCP terão que ser configuradas / desativadas. Tentamos mitigar isso mantendo as conexões vivas o maior tempo possível. Mas, no final, o desempenho accept () é o que impede nossos núcleos de girarem e não gostamos disso.
Atualização 1
Alguém postou esta pergunta no Hacker News , também há algumas perguntas / respostas. Mas tentarei manter essa pergunta atualizada com as informações que encontrar à medida que for avançando.
Hardware / plataformas Eu testei isso em:
- EC2 com tipos de instância c1.xlarge (8 núcleos, 7 GB de RAM) e cc1.4xlarge (2x Intel Xeon X5570, 23 GB de RAM). As AMIs utilizadas foram ami-08f40561 e ami-1cad5275, respectivamente. Alguém também apontou que os "Grupos de Segurança" (ou seja, o firewall do EC2s) também podem afetar. Mas para esse cenário de teste, tentei apenas no host local para eliminar fatores externos como esse. Outro boato que ouvi é que instâncias do EC2 não podem enviar mais do que 100k PPS.
- Dois servidores virtualizados particulares executando o Xen. Um deles tinha carga zero antes do teste, mas não fez diferença.
- Servidor Xen dedicado dedicado na Rackspace. Sobre os mesmos resultados lá.
Estou no processo de reexecutar esses testes e preencher os relatórios em https://gist.github.com/985475 Se você quiser ajudar, contribua com seus números. É fácil!
(O plano de ação foi movido para uma resposta consolidada separada)