Benchmark de servidores em nuvem e especificações infladas: identificando e evitando CPUs antigos

Três evidências desmascaram a mentira do preço premium de CPUs antigos

Atualizado 2026-08-25 · CloudWorth

BenchmarkEspecificações infladasSteal TimeOversellingCusto-benefícioCloudWorthOverselling VPSBenchmark VPS

Use Steal Time + Cache de disco + benchmark real em três verificações para se recusar a pagar prêmio por CPUs antigos.

Quão longe a pontuação real está da nominal

A diferença entre a pontuação de benchmark de servidores em nuvem e a configuração nominal costuma ser maior do que se imagina. Especialmente em CPUs antigas que ostentam “alta frequência”, como os Xeons de 2016, E5-2690 v4 e E5-2680 v4, a frequência de núcleo único parece alta, mas na prática, ao testar, a pontuação de thread única pode ser apenas metade da de um Xeon de geração nova. As principais causas da “pontuação inflada” são duas: diferenças de geração de hardware e o aumento do Steal Time devido a overcommit.

Em plataformas antigas com virtualização, o campo steal em /proc/stat mostra o tempo em que a CPU foi tomada pelo hypervisor. Se o mpstat -P ALL 1 mostrar %steal acima de 10% por um longo período, significa que os vizinhos estão disputando recursos com você; nesse caso, não importa quão alta seja a especificação, o benchmark não será estável. Outro indicador sutil é o “despenhadeiro” do cache de disco — em armazenamentos antigos com CPUs antigas, quando o cache acaba, o IOPS cai pela metade, e a curva de benchmark tem uma queda visível.

Para quantificar a diferença, execute um yabs ou sysbench cpu --threads=1 run e compare com a especificação oficial. Já vi plataformas antigas anunciadas como 3.5GHz que, na prática, tiveram uma pontuação de núcleo único 40% menor que uma plataforma nova de 2.9GHz. Ou seja, o que você paga por “alta frequência + configuração antiga” pode ser, em parte, um prêmio por hardware de segunda mão. Esse é exatamente o tipo mais típico de custo negativo em FinOps: com o mesmo orçamento, escolher plataformas novas ou instâncias oficialmente certificadas resulta em menor custo por unidade de computação.

Portanto, não olhe apenas para os parâmetros nominais. Recomendo usar o CloudWorth para filtrar instâncias com base nos benchmarks reais e nos limites de Steal Time, gastando seu orçamento em desempenho real.

Steal Time: detectando superprovisionamento

Para enxergar por trás das configurações infladas de servidores cloud, o primeiro passo é examinar o steal time. Essa métrica é um sinal do Hypervisor para você: quando a CPU física é cedida pelo locador à VM vizinha, seus vCPUs ficam esperando. Use o top, pressione C para alternar para a lista de CPUs, depois t para ver a coluna steal, ou execute vmstat 1 para observar o campo st. Faça amostragens repetidas por alguns minutos; se a média de st ultrapassar 5%, ou até houver picos chegando a 20%+, parabéns: você está compartilhando o mesmo núcleo físico com vizinhos problemáticos.

# Amostre 10 vezes com intervalo de 1 segundo e calcule a média do st
vmstat 1 10 | awk 'NR>3 {sum+=$16} END {print "avg steal:", sum/(NR-3), "%"}'

Picos de Steal Time são mais alarmantes do que valores altos constantes — eles indicam que o superprovisionamento é dinâmico e, em horários de pico, seu tempo de resposta pode oscilar aleatoriamente como um eletrocardiograma. Combinado com o colapso do cache de disco mencionado na seção anterior, isso praticamente confirma que este é um host antigo sendo repetidamente sublocado.

Do ponto de vista do FinOps, isso é uma fraude de preço premium: você paga o preço de hardware novo, mas recebe restos de uma CPU antiga fatiada, com uma taxa de prêmio que chega a quase três vezes a da nuvem pública. Não se iluda com clocks altos; por mais potente que seja um núcleo de um Xeon antigo, ele não aguenta a corrida dos vizinhos. Antes de rodar benchmarks, verifique o steal; caso contrário, por mais bonitos que sejam os números do Geekbench, são apenas miragens em uma caixa de areia superprovisionada. Essa métrica é gratuita, reproduzível e mais honesta do que qualquer promessa de fornecedor.

Investigação do precipício de cache de disco

Antes, usamos o Steal Time para detectar overselling, mas alguns data centers antigos conseguem deixar o agendamento da CPU muito nivelado, e os dados de Steal acabam não parecendo tão ruins. Nesse momento, não tire conclusões precipitadas — mude o foco para o cache de disco, que é um dos hardwares que menos mentem.

Na prática, costumo usar o fio para rodar duas vezes em sequência: primeiro testo a escrita com buffer (buffered write), que usa o Page Cache, e depois testo a escrita direta (direct write), que ignora o cache. Os comandos são mais ou menos assim:

# Primeira rodada: escrita com buffer (consome cache de memória)
fio --name=cache-test --rw=write --bs=1M --size=2G --direct=0 --ioengine=libaio --runtime=30 --time_based

# Segunda rodada: escrita direta (ignora cache, grava direto no disco)
fio --name=direct-test --rw=write --bs=1M --size=2G --direct=1 --ioengine=libaio --runtime=30 --time_based

O ponto principal é observar a "proporção do precipício" entre os dois valores. Em discos NVMe novos, a escrita direta fica em torno de 60% a 80% da escrita com buffer; em discos mecânicos antigos ou armazenamento compartilhado, a escrita direta pode despencar para menos de 10%. Se o valor nominal é 2000 MB/s, mas a escrita direta é de apenas 150 MB/s, isso é um caso típico de precipício de cache — os dados enganam primeiro, e só quando chegam ao disco é que a verdade aparece.

Essa investigação precisa ser analisada em conjunto com o Steal Time. Steal alto indica que o vizinho está roubando CPU, e o precipício no disco indica que o canal de armazenamento também está congestionado — com essas duas evidências combinadas, dá para concluir que há overselling, e não um overselling qualquer, mas aquele em que até o hardware subjacente é de dar dó.

Do ponto de vista de FinOps, esse tipo de máquina deveria ser precificado pelo "valor residual". Se o prêmio sobre a configuração nominal passar de 30% em comparação com uma máquina nova, pode cortar na hora; se não conseguir cortar, troque. Afinal, você está pagando pela especificação (Spec), não pela miragem no cache. O guia completo para evitar armadilhas está em Guia de verificação de especificações infladas para servidores em nuvem.

Árvore de decisão para sobrepreço e prevenção de armadilhas

Ao pegar um servidor em nuvem com 'CPU antiga de alta frequência', não se apresse em pagar. Primeiro, calcule a taxa de sobrepreço: (pagamento mensal real - preço de mercado de uma CPU nova com a mesma configuração) / preço de mercado de uma CPU nova com a mesma configuração. Se o sobrepreço ultrapassar 30%, basicamente dá para afirmar que você está pagando imposto de burrice por hardware aposentado. Uma jogada mais agressiva é quantificar diretamente pela ótica de FinOps: com o mesmo dinheiro, você consegue comprar uma AMD EPYC com o dobro de núcleos ou um Intel novo de 3 anos? Se sim, essa compra não deveria ser aprovada.

Em seguida, siga minha árvore de decisão forense tripla:

1. Steal Time: pegue o vizinho malicioso

   vmstat 1 10 | awk '{print $17}'  # 看 st 列

Em amostragens consecutivas, se a média de st for > 5%, ou se houver picos acima de 20%, isso indica que o host está com overselling severo, o tempo de CPU está sendo roubado pelo vizinho, e reduzir a configuração é a única forma de estancar o prejuízo.

1. Teste do precipício do cache de disco

   dd if=/dev/zero of=/tmp/test bs=1M count=1024 conv=fdatasync

A primeira gravação em cache atinge 1,5 GB/s, a segunda cai direto para 150 MB/s, o cache está 'enxugando', típico de overselling de armazenamento compartilhado. Configuração antiga + precipício de disco = dupla especificação falsa.

1. Comparação de benchmark real

   curl -sL yabs.sh | bash

Se o Geekbench 5 de núcleo único estiver abaixo de 700, mas a frequência nominal for 3,5 GHz? Leve esse relatório diretamente ao suporte e exija reembolso pela diferença de uma nova CPU de 4 núcleos ou migração.

Por fim, uma regra rígida: qualquer página de divulgação que prometa 'alto desempenho', mas não forneça link de benchmark real antes da venda, deve ser tratada como especificação falsa de configuração. Confie apenas no seu próprio benchmark, pague o sobrepreço apenas por uma CPU nova.