Explique este estranho problema de desempenho relacionado ao ambiente relacionado ao Ruby

Question

Estamos diagnosticando problemas de desempenho do Ruby em nossos servidores de aplicativos, conseguimos reduzir a um simples caso de teste.

Comparamos o desempenho de uma máquina em nosso cluster de desenvolvimento a uma máquina em nosso centro de dados de produção.

Usamos este onlininer simples de Ruby:

5000000.times { a = []; a << 1; a.length }

E nós o comparamos como sendo consistentemente 55% mais lento na máquina de produção.

Coisas que obviamente poderiam ser e por que achamos que não é:

1. Diferentes softwares - dev e máquinas de produção são instalados a partir do mesmo ubuntu os, scripts de instalação do ubuntu, repositórios de pacotes, e usamos o fantoche para manter as configurações consistentes.
2. Hardware diferente - possivelmente, mas veja abaixo.
3. Carga diferente - nem as máquinas de desenvolvimento nem de produção são significativamente carregadas e, novamente, veja abaixo.

Por que não achamos que é carga ou hardware?

Primeiro, eles têm cargas e configurações de hardware semelhantes. Em segundo lugar, escrevemos um script de teste python:

n = 10000000
while n > 1:
  n = n - 1
  a = []
  a.append(4)
  len(a)

e isso é consistentemente 10% mais rápido na produção do que no desenvolvimento, que é o que esperamos. Se o problema fosse carga ou hardware, o Python também não seria mais lento na produção?

Resumidamente, as duas máquinas são virtualizadas usando o ESXi

• o desenvolvimento vm tem 4GB de RAM e hospedado em uma máquina com AMD quad-core dual dual-core 2376 @ 2.294Ghz 32GB fornecendo um núcleo virtual para a vm

• produção

  vm tem 4GB de RAM e hospedado em uma máquina com dual quad-core AMD Opteron 2354 @ 2.211Ghz 32GB fornecendo quatro núcleos virtuais para a VM (atualização: já tentamos com um núcleo virtual em todos os vms e não fez diferença)

O sistema operacional é o Ubuntu Hardy de 64 bits. Nosso intérprete de Ruby é:

ruby 1.8.6 (2008-08-11 patchlevel 287) [x86_64-linux]

e nosso interpretador python é

Python 2.5.2 (r252:60911, Jul 31 2008, 17:31:22)

NB. Nós também tentamos isso com o Ruby Enterprise Edition, e os resultados são os mesmos.

    

Answer 1

Eu não faço a menor idéia do que está acontecendo, mas eu pensei em compartilhar algumas outras diferenças de hardware, baseadas nos processadores, para ver se isso ajuda alguém a se aproximar da resposta.

• O Opteron 2354 tem 2MB de cache L-3, onde o 2376 tem 6MB.
• O 2354 usa o PC2-5300 DDR2 RAM, em que o 2376 usa o PC2-6400 DDR2 RAM.

Estou um pouco enferrujado com hardware, mas suponho que isso significa que o acesso à memória em geral é significativamente mais rápido na máquina de desenvolvimento? Então, se Ruby estava sendo, de alguma forma, mais "intensivo de memória" (e eu realmente não sei o que quero dizer com isso!), Então ele poderia aparecer como uma diferença de desempenho maior?

(Eu fui procurar para ver se havia algum recurso de virtualização no processador mais novo que poderia explicar a diferença, mas surgiu em branco.)

Algumas perguntas ...

• Quais são as outras VMs em cada servidor?
• Você vê o mesmo comportamento com outro (não baseado em MRI) Ruby, JRuby talvez?
• Você pode executar a amostra com ltrace / strace, ver onde o tempo está sendo gasto? Veja Depuração do Ruby: Entendendo e solucionando problemas na VM e seu aplicativo para mais detalhes.

Answer 2

Você já tentou REDUZIR o número de vCPUs que está fornecendo para a VM de produção?

Eu sei que soa contraproducente, mas, e você já deve estar ciente disso, o ESX não dará a VM QUALQUER tempo de CPU se TODOS os slots de vCPU alocados a qualquer VM não forem gratuitos - ou seja, se uma VM tiver 4 vCPUs atribuídas a ele e elas não são todas gratuitas, então a VM não recebe tempo algum. Eu sei que parece mental, mas seriamente tentar cair para 2 ou 1 vCPUs e executá-lo novamente.

Melhor da sorte.

    

Answer 3

Na verdade, esta é a avenida em que eu estava pensando também. Com o cache sendo menor no servidor de produção, ele irá esgotar isso mais rapidamente e terá que recorrer ao uso da memória principal. Se esse acesso for mais lento na produção do que no desenvolvimento, isso pode explicar o problema.

No entanto, esse mesmo problema também deveria ou deveria acontecer com o Python. Como o Ruby e o Python são implementados em C, o tamanho inteiro provavelmente seria o mesmo (essa suposição pode estar errada).

Em suma, ainda estou procurando!

    

Answer 4

Pergunta: como você está fazendo o benchmarking? Você está usando o benchmark do ruby para a versão ruby ou alguma ferramenta externa? Se o primeiro, eu estou querendo saber se é algo na biblioteca de benchmark que está causando o problema.

    

Answer 5

Eu tive um problema semelhante na semana passada em nosso sistema. Acontece que foi porque alguém tinha instalado / requerido o activesupport que estava modificando um monte de coisas em nossa pilha de classes e causando uma desaceleração. Isso foi detectado apenas ao executar o tráfego real. Verifique as gemas instaladas no sistema lento e compare as versões com a máquina de desenvolvimento. Seu possível algo está fora de sintonia.

    

Answer 6

Eu geralmente desconfio do desempenho do VMWare, então ficaria muito interessado em ver o que aconteceria se eles tivessem a mesma configuração de vmware.

Uhh ... só para ter certeza, o que acontece quando você faz:

 n = 1000000
 while n > 1 do
   n = n - 1
   a = []
   a.push 4
   a.length
 end

Eu sei que é funcionalmente equivalente a 1000000.times { a = []; a << 4; a.length } , mas a função do tempo pode estar fazendo algo funky nos bastidores? Eu também concordo com a afirmação sobre encadeamento, mas isso efetivamente significa que a caixa dev é apenas 0.083Ghz mais rápida - o que provavelmente não é responsável por uma queda de 55%. Seria interessante ver o que o Ruby 1.9 faz, mas se você tentou o REE, duvido que a diferença de desempenho seja muito grande. Estou assumindo que é exatamente a mesma velocidade de disco, caches de memória, etc?

    

Answer 7

É porque o Ruby não pode tirar proveito dos núcleos virtuais extras devido ao fato de estarem com threads verdes enquanto o Python com threading nativo pode? (Bunda selvagem adivinhando aqui - eu realmente não sei do que estou falando).