Velocidade de diferentes distribuições do Linux - por que a diferença?

Question

Eu tenho um software multi-threaded que roda em diferentes velocidades sob o mais recente servidor ubuntu, redhat enterprise e CentOS - todos instalados no mesmo servidor para comparação.

O servidor Ubuntu ficou mais lento, seguido pelo CentOS e, em seguida, pelo redhat enterprise. A diferença foi de 10 a 20%.

A diferença entre o centOS e o redhat pode ser explicada por uma nova versão do gcc, mas pelo menos nos dois últimos sistemas operacionais a mesma versão do gcc foi usada.

O que eu pude ver na execução do ubuntu é que, embora o programa usasse, digamos, 13 núcleos, o total de CPU informado por "top" era de 1220%, enquanto no redhat (e centOS) era 1300%

Alguém tem uma explicação? Eu prefiro trabalhar com o Ubuntu (é grátis), mas não posso arcar com a lentidão. Eu tentei outros benchmarks multithreaded que pareciam indicar também que o Ubuntu é um pouco mais lento - no mesmo executável baixado, não compilado localmente.

    

Answer 1

Esta não é uma resposta conclusiva, apenas alguns pensamentos que são muito longos para um comentário.

1. Tente com atop em vez de top . Ele fornece uma visão muito melhor do que está acontecendo. Acho que a saída de top também é muito inconsistente nos dias de hoje. Eu não tenho nenhuma explicação sobre o porquê, mas eu vi o mesmo comportamento que você tem com vários núcleos.

2. Essas instalações estão dentro do VMWare por acaso? Eu executei alguns benchmarks usando várias ferramentas em 5 VMs diferentes executando 5 distros diferentes: Ubuntu, CentOS, RHEL, SUSE e Debian. Tive resultados divergentes que não pareciam se correlacionar com nada que eu pudesse encontrar. O conselho que recebi quando a enviei para a Red Hat foi que alguns kernels de distribuição são melhor otimizados para VMWare do que outros. Isso foi há vários anos, embora as coisas possam ter mudado.

3. Você consegue descrever melhor o comparativo interno que está sendo executado no seu aplicativo? Esta questão poderia facilmente ficar entre o serverfault e o stackoverflow ...