Por que o desempenho do TCP accept () é tão ruim com o Xen?

Question

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 aumento de velocidade de 3-5x.

1. Por que isso é tão ruim com o Xen?
2. Você pode ajustar o Xen para melhorar o desempenho de novas conexões TCP?
3. Existem outras plataformas de virtualização mais adequadas para esse tipo de caso de uso?

Antecedentes

Ultimamente, venho pesquisando alguns gargalos de desempenho de um servidor Java desenvolvido internamente e executado sob o Xen. O servidor fala HTTP e responde a simples chamadas TCP connect / request / response / disconnect.

Mas mesmo durante o envio de cargas de tráfego para o servidor, ele não pode aceitar mais de aproximadamente 7000 conexões TCP por segundo (em uma instância EC2 de 8 núcleos, c1.xlarge executando Xen). Durante o teste, o servidor também exibe um comportamento estranho em que um núcleo (não necessariamente 0) fica muito carregado > 80%, enquanto os outros núcleos ficam quase ociosos. 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 e bare-metal, obtenho resultados de teste mostrando taxas TCP aceitas () além de 35.000 / segundo. Isso em uma máquina Core i5 4 core rodando Ubuntu com todos os núcleos quase totalmente saturados. Para mim, esse tipo de figura parece certo.

Na instância do Xen, tentei ativar / ajustar quase todas as configurações do sysctl.conf. Incluindo a ativação do Receive Packet Steering e Receive Flow Direcionando e fixando threads / processos para CPUs, mas sem ganhos aparentes.

Eu sei que desempenho degradado é esperado ao executar virtualizado. Mas a este grau? Um servidor de metal mais lento superando o virt. 8-core por um fator de 5?

1. Esse comportamento é realmente esperado de Xen?
2. Você pode ajustar o Xen para melhorar o desempenho de novas conexões TCP?
3. Existem outras plataformas de virtualização mais adequadas para esse tipo de caso de uso?

Reproduzindo esse comportamento

Quando investigando isso e identificando o problema, descobri que a ferramenta de teste de desempenho netperf poderia simular o cenário semelhante que estou tendo. Usando o teste TCP_CRR do netperf, coletei vários relatórios de diferentes servidores (virtualizados e não-virt.). Se você quiser contribuir com algumas descobertas ou consultar meus relatórios atuais, consulte o link

Como sei que este problema não se deve a software mal escrito?

1. O servidor foi testado em hardware bare-metal e quase satura todos os núcleos disponíveis para ele.
2. Ao usar conexões TCP de manutenção, o problema desaparece.

Por que isso é importante?

No ESN (meu empregador), sou o líder do projeto de Beaconpush , um servidor Comet / Web Socket escrito em Java. Mesmo que seja muito eficiente e possa saturar praticamente qualquer largura de banda fornecida sob condições ótimas, ainda assim é limitado a velocidade 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êm e vão com frequência, muitas conexões TCP terão que ser configuradas / desmontadas. Tentamos atenuar isso mantendo as conexões ativas pelo maior tempo possível. Mas no final, o desempenho de accept () é o que impede nossos núcleos de girar e não gostamos disso.

Atualização 1

Alguém postou esta pergunta no Hacker News , também tem algumas perguntas / respostas. Mas vou tentar manter esta questão atualizada com as informações que encontrar enquanto prossigo.

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). Os AMIs utilizados foram ami-08f40561 e ami-1cad5275, respectivamente. Alguém também apontou que os "Grupos de Segurança" (ou seja, firewall do EC2s) também podem afetar. Mas para este cenário de teste, eu tentei apenas no localhost para eliminar fatores externos como este. Outro boato que ouvi é que as instâncias do EC2 não podem enviar mais de 100k PPS.
• Dois servidores virtualizados privados que executam o Xen. Um deles tinha carga zero antes do teste, mas não fez diferença.
• Private dedicado, Xen-server na Rackspace. Sobre os mesmos resultados lá.

Estou no processo de reexecutar esses testes e preencher os relatórios no link Se você quiser ajude, contribua com seus números. É fácil!

(o plano de ação foi movido para uma resposta separada e consolidada)

    

Answer 1

Agora: o desempenho de pacotes pequenos é uma droga do Xen

(movido da pergunta em si para uma resposta separada)

De acordo com um usuário na HN (um desenvolvedor KVM?), isso se deve ao pequeno desempenho do pacote no Xen e também no KVM. É um problema conhecido com virtualização e, de acordo com ele, o ESX da VMWare trata isso muito melhor. Ele também observou que o KVM está trazendo alguns novos recursos projetados para aliviar isso ( postagem original ).

Esta informação é um pouco desanimadora se estiver correta. De qualquer forma, vou tentar os passos abaixo até que algum guru Xen venha com uma resposta definitiva:)

Iain Kay, da lista de discussão xen-users, compilou este gráfico: ObserveasbarrasTCP_CRR,compare"2.6.18-239.9.1.el5" vs "2.6.39 (com o Xen 4.1.0)".

Plano de ação atual com base nas respostas / respostas aqui e de HN :

1. Envie este problema para uma lista de discussão específica do Xen e bugzilla do xensource como sugerido por syneticon-dj Uma mensagem foi postada na lista de usuários xen , aguardando resposta.

2. Crie um caso de teste patológico simples no nível do aplicativo e publique-o.
   Um servidor de teste com instruções foi criado e publicado no GitHub . Com isso, você poderá ver um caso de uso mais real em comparação com o netperf.

3. Tente uma instância guest de PV Xen de 32 bits, pois o 64-bit pode estar causando mais sobrecarga no Xen. Alguém mencionou isso em HN. Não fez diferença.

4. Tente ativar o net.ipv4.tcp_syncookies no sysctl.conf, como sugerido por abofh no HN. Isso aparentemente pode melhorar o desempenho, já que o handshake ocorreria no kernel. Eu não tive sorte com isso.

5. Aumente o backlog de 1024 para algo muito mais alto, também sugerido por abofh no HN. Isso também poderia ajudar, já que guest poderia potencialmente aceitar () mais conexões durante sua fatia de execução dada por dom0 (o host).

6. Verifique se o conntrack está desativado em todas as máquinas, pois ele pode reduzir pela metade a taxa de aceitação (sugerida por deubeulyou). Sim, foi desativado em todos os testes.

7. Verifique se há "estouro da fila de escuta e estouro de depósitos no syncache no netstat -s" (sugerido por mike_esspe no HN).

8. Divida a manipulação de interrupção entre vários núcleos (o RPS / RFS que eu tentei habilitar anteriormente deve fazer isso, mas pode valer a pena tentar novamente). Sugerido por adamt no HN.

9. Desativando o descarregamento de segmentação TCP e a aceleração de dispersão / coleta, conforme sugerido por Matt Bailey. (Não é possível no EC2 ou em hosts VPS semelhantes)

Answer 2

Curiosamente, descobri que desligar a aceleração de hardware da NIC melhora muito o desempenho da rede no controlador Xen (também verdadeiro para o LXC):

Scatter-gather accell:

/usr/sbin/ethtool -K br0 sg off

Descarregamento de segmentação TCP:

/usr/sbin/ethtool -K br0 tso off

Onde br0 é sua ponte ou dispositivo de rede no host do hipervisor. Você terá que configurar isso para desligá-lo a cada inicialização. YMMV.

    

Answer 3

Talvez você possa esclarecer um pouco: você executou os testes no Xen em seu próprio servidor ou apenas em uma instância do EC2?

Aceitar é apenas outro syscall, e novas conexões são diferentes apenas porque os primeiros pacotes terão alguns flags específicos - um hypervisor como o Xen definitivamente não deve ver nenhuma diferença. Outras partes de sua configuração podem: no EC2, por exemplo, eu não ficaria surpreso se os grupos de segurança tivessem algo a ver com isso; A conntrack também é relatada para reduzir pela metade a taxa de aceitação de novas conexões (PDF) .

Por fim, parece haver combinações de CPU / Kernel que causam uso / desligamentos estranhos da CPU no EC2 (e provavelmente no Xen em geral), como blogado recentemente por Librato .

    

Answer 4

Certifique-se de ter desabilitado iptables e outros ganchos no código de bridging em dom0. Obviamente, isso só se aplica à configuração de ponte Xen em rede.

echo 0 > /proc/sys/net/bridge/bridge-nf-call-ip6tables
echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables
echo 0 > /proc/sys/net/bridge.bridge-nf-call-arptables

Depende do tamanho do servidor, mas dos menores (processador de 4 núcleos) dedicam um núcleo de CPU ao Xen dom0 e o fixam. Opções de inicialização do hipervisor:

dom0_max_vcpus=1 dom0_vcpus_pin dom0_mem=<at least 512M>

Você tentou passar o dispositivo PCI ethernet físico para domU? Deve haver um bom aumento de desempenho.