Como fazer benchmark de VPS corretamente

O que significa fazer benchmark em um VPS

Para fazer benchmark de um VPS, você mede quatro aspectos: a velocidade de execução de um único núcleo de CPU, a largura de banda de memória disponível na máquina, quantas operações de disco pequenas e aleatórias o armazenamento atende por segundo e a taxa de transferência fornecida pelo link de rede. Uma execução de yabs.sh fornece os quatro resultados em cerca de dez minutos. Interpretar o resultado é mais difícil, porque um VPS (servidor virtual privado) compartilha o hardware físico com outros clientes. Por isso, a mesma máquina pode informar um valor às 03:00 e um valor muito diferente às 20:00.

O plano é executar yabs.sh para obter uma visão rápida e depois executar manualmente as ferramentas usadas por ele. Executá-las por conta própria permite alterar uma flag, monitorar a variação do valor e entender o que esse valor realmente estava medindo. Faça isso depois de configurar a máquina, não antes. As etapas de os primeiros dez minutos em um VPS novo vêm primeiro, porque um servidor que ainda está aplicando sua primeira rodada de atualizações apresenta resultados ruins no benchmark por motivos que não têm relação com o hardware.

Analise a maquina antes de medi-la

Metade de todo benchmark ruim resulta de uma maquina que o autor nao entendeu.

nproc
lscpu | grep -E 'Model name|Hypervisor|Thread'
free -h
df -hT /
uname -r
systemd-detect-virt

Hypervisor vendor: KVM significa virtualizacao completa, portanto voce executa seu proprio kernel. systemd-detect-virt exibindo lxc ou openvz significa virtualizacao por contêiner em vez disso: voce compartilha o kernel do host, e os limites de CPU e memoria sao configuracoes de cgroup (control group), nao hardware virtual. Em um sistema com cgroup v2, voce pode ler diretamente o limite de CPU.

cat /sys/fs/cgroup/cpu.max

max 100000 significa que nao ha cota. 200000 100000 significa que voce pode usar 200000 microssegundos de CPU em cada periodo de 100000 microssegundos, o que equivale a uma cota de dois cores. Um plano anunciado como 4 vCPU com uma cota de dois cores nunca tera uma pontuacao equivalente a quatro cores, e nenhuma ferramenta de benchmark exibira uma linha explicando o motivo.

df -hT / importa por outro motivo: a coluna Type. Se ela mostrar overlay, voce esta dentro de um contêiner, e o teste de disco abaixo precisa de uma alteracao. Anote isso agora.

Monitore o tempo de steal durante todo o teste

O tempo de steal é a parcela do tempo em que sua CPU virtual estava pronta para executar, mas o hypervisor entregou o núcleo físico a outra máquina virtual. Esse é o sinal isolado mais útil para indicar que um resultado é causado por seus vizinhos, e não pelo hardware.

vmstat 1 10

Leia a coluna st à direita. Um valor constante de 0 ou 1 é normal. Valores sustentados acima de 5 indicam que o host está superalocado naquele momento. Portanto, todos os valores de CPU registrados nessa janela ficam baixos sem que haja falha na sua máquina. top mostra o mesmo valor que %st na linha da CPU. Mantenha vmstat 1 em execução em uma segunda sessão SSH enquanto executa o benchmark e anote o valor de steal ao lado de cada resultado.

Comece com yabs.sh

yabs.sh (Yet Another Bench Script) é um script shell que baixa binários estáticos de fio, iperf3 e Geekbench, executa-os e exibe um único resumo. Ele é a linguagem comum das discussões sobre benchmarks de VPS. Por isso, uma saída do yabs é a forma mais rápida de comparar resultados com outra pessoa.

O próprio projeto fornece este comando de uma linha.

curl -sL yabs.sh | bash

Esse comando envia diretamente para um shell o conteúdo que a URL disponibilizar hoje. Baixe o script, leia-o e depois execute-o.

curl -sLo yabs.sh https://raw.githubusercontent.com/masonr/yet-another-bench-script/master/yabs.sh
less yabs.sh
bash yabs.sh

Os flags são informados depois de -s -- quando você usa um pipe, ou diretamente depois do nome do arquivo quando executa uma cópia local. Os mais úteis são: -f ignora o teste de disco, -i ignora o teste de rede, -g ignora o Geekbench, -r reduz para dois os locais usados pelo iperf3, -j exibe os resultados em JSON e -w results.json grava esse JSON em um arquivo.

bash yabs.sh -r -w yabs-run1.json

Antes da primeira execução, há dois pontos importantes. O Geekbench envia o resultado e exibe uma URL pública em browser.geekbench.com. Qualquer pessoa que tenha esse link pode consultar o modelo da CPU e as pontuações. -g ignora completamente esse teste. Além disso, a etapa do iperf3 gera tráfego de rede real para servidores em várias regiões, e esse tráfego é descontado da sua franquia mensal. Em um link de 1 Gbit/s, uma etapa de rede completa pode transferir dezenas de gigabytes. Portanto, use -r quando a franquia for pequena e -i em um link tarifado.

O que cada parte da saída do yabs significa

A seção de disco executa o fio com uma combinação de leitura e gravação de 50/50, usando quatro tamanhos de bloco: 4k, 64k, 512k e 1m. Ela informa os IOPS (operações de entrada/saída por segundo) e a largura de banda de cada um. A linha 4k é a mais importante para um banco de dados, um servidor de e-mail ou qualquer sistema que execute muitas gravações pequenas, porque a maior parte da E/S do servidor é pequena e dispersa. A linha 1m é importante para backups e vídeo, quando você move sequências longas de bytes.

A seção de rede executa o iperf3 contra servidores públicos em várias regiões, nas duas direções, usando fluxos paralelos. Considere um número baixo como uma questão, não como uma resposta, porque os servidores públicos do iperf3 são compartilhados e frequentemente ficam saturados. Portanto, um resultado ruim pode estar relacionado ao outro extremo.

A seção do Geekbench apresenta uma pontuação de núcleo único e uma pontuação de múltiplos núcleos. O resultado de núcleo único indica a velocidade com que uma solicitação, uma compilação ou uma consulta é concluída. O resultado de múltiplos núcleos informa principalmente quantos núcleos você realmente recebeu.

Disco: execute o fio diretamente

fio (flexible IO tester) é a ferramenta usada na seção de disco do yabs. Executá-la diretamente mostra o que cada flag realmente faz.

sudo apt update && sudo apt install -y fio sysbench iperf3

Um teste de leitura aleatória de 4k, com profundidade de fila 32, no sistema de arquivos que você realmente quer avaliar:

fio --name=randread4k --filename=./fio-testfile --size=2G --bs=4k \
  --rw=randread --ioengine=libaio --iodepth=32 --direct=1 \
  --runtime=60 --time_based --group_reporting

A linha de resumo que você deve ler na saída tem esta aparência.

read: IOPS=184k, BW=719MiB/s (754MB/s)(42.1GiB/60001msec)

Abaixo dela, o fio imprime um bloco clat percentiles. O percentil 99.00 é o valor mais relevante, porque mostra quanto tempo demorou a solicitação mais lenta entre 100. A latência média oculta exatamente as esperas que o usuário percebe.

• --direct=1 abre o arquivo com O_DIRECT, para que as leituras ignorem o cache de páginas do kernel. Sem essa opção, a segunda passagem por um arquivo de 2G em uma máquina com 8G de RAM é atendida pela memória, e o fio informa IOPS na casa dos milhões. Esse número é real, mas representa a memória.
• --ioengine=libaio envia solicitações assíncronas. Isso permite que --iodepth=32 mantenha 32 solicitações em andamento. Com um mecanismo síncrono, como psync, um iodepth acima de 1 não produz efeito algum. Nesse caso, você mede uma solicitação por vez.
• --time_based --runtime=60 executa o teste por 60 segundos fixos, em vez de usar uma quantidade fixa de trabalho. Assim, um disco rápido e um disco lento usam o mesmo tempo de execução, e a comparação permanece justa.
• --size=2G define o tamanho do arquivo de teste. Mantenha-o maior que qualquer cache no caminho e confirme primeiro se há espaço livre suficiente.

A gravação aleatória usa o mesmo comando com --rw=randwrite. Execute-a separadamente e exclua o arquivo depois.

fio --name=randwrite4k --filename=./fio-testfile --size=2G --bs=4k \
  --rw=randwrite --ioengine=libaio --iodepth=32 --direct=1 \
  --runtime=60 --time_based --group_reporting
rm -f ./fio-testfile

Para uma combinação mais próxima do tráfego real, use --rw=randrw --rwmixread=70. A classe de armazenamento usada altera esses resultados mais do que qualquer flag. Essa diferença é explicada em a diferença entre armazenamento NVMe e SSD SATA em um VPS.

Quando o fio termina com Unknown error -1

A E/S direta não está disponível em todos os sistemas de arquivos. overlay, o sistema de arquivos que o Docker fornece a um contêiner por padrão, e vários sistemas de arquivos de rede não oferecem suporte a O_DIRECT. Por isso, o libaio envia uma solicitação que o kernel não consegue concluir, e o fio desiste:

fio: io_u error on file ./fio-testfile: Unknown error -1: read offset=0, buflen=4096
fio: pid=1234, err=-1/file:ioengines.c:321, func=get_events, error=Unknown error -1

Execute df -hT . primeiro. Se a coluna Type informar overlay, aponte --filename para um caminho em armazenamento real, como um volume montado com bind, ou execute o fio no host em vez de executá-lo no contêiner. Se o armazenamento real não estiver acessível, uma execução síncrona com buffer pelo menos confirma que o comando está correto.

fio --name=randread4k-buffered --filename=./fio-testfile --size=256M --bs=4k \
  --rw=randread --ioengine=psync --direct=0 --numjobs=1 \
  --runtime=15 --time_based --group_reporting
rm -f ./fio-testfile

Seja preciso sobre o que essa execução mede. Após a primeira passagem, o arquivo de 256M permanece no cache de páginas, portanto o valor de IOPS descreve a sua RAM. Use-o para confirmar que o fio está instalado e que as opções são interpretadas corretamente. Nunca o apresente como um resultado de disco.

Por que dd não é um benchmark de disco

dd aparece em muitos tópicos sobre VPS e responde a uma pergunta específica.

dd if=/dev/zero of=./ddtest bs=1M count=1024 oflag=direct conv=fdatasync
rm -f ./ddtest

Isso mede a taxa de transferência de gravação sequencial com uma thread e uma solicitação em andamento. É uma verificação básica razoável. Não informa nada sobre E/S aleatória nem sobre o que acontece quando 32 solicitações chegam ao mesmo tempo. Remova oflag=direct e ele passa a medir principalmente a rapidez com que o kernel aceita gravações na memória. Por isso, os valores de dd citados em publicações de fóruns costumam ser absurdos.

CPU: sysbench cpu

sysbench cpu --cpu-max-prime=20000 --threads=1 run
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) run

O resultado a ser considerado é events per second. Execute primeiro com uma única thread. Esse é o valor que determina a rapidez com que uma requisição PHP termina ou uma tarefa de compilação é concluída, e é o que mais varia entre hosts com o mesmo preço. Depois, execute com todas as threads. Isso mostra se suas vCPUs são núcleos separados ou partes de um único núcleo.

É importante entender o que esse teste mede: o sysbench encontra repetidamente números primos usando aritmética inteira de 64 bits. Ele não exerce pressão sobre a largura de banda da memória, as unidades vetoriais ou o cache de uma forma semelhante a uma carga de trabalho real. Por isso, é útil para classificar dois hosts, mas não para prever como seu aplicativo será executado.

O Ubuntu 24.04 inclui o sysbench 1.0.20, no qual o nome do teste vem primeiro. Se você copiar de uma publicação antiga um comando com --test=cpu, obterá WARNING: the --test option is deprecated. Os resultados do sysbench 0.4 e do sysbench 1.0 não são comparáveis de forma alguma. Portanto, nunca compare seu resultado com um número publicado que não informe a versão utilizada.

Memória: sysbench memory

sysbench memory --memory-block-size=1M --memory-total-size=20G --memory-oper=write --threads=1 run
sysbench memory --memory-block-size=1M --memory-total-size=20G --memory-oper=read --threads=1 run

O resultado é expresso em MiB/sec, e as leituras são mais rápidas que as gravações em todas as máquinas. Mantenha --memory-block-size em 1M e use exatamente o mesmo valor em todos os hosts comparados. Em 1K, o número cai porque a sobrecarga por operação ocorre mil vezes mais, e você acaba medindo o custo do loop em vez da largura de banda da memória. Essa é a flag com maior frequência de inconsistências nos resultados de memória publicados.

Rede: iperf3

A forma correta de testar a taxa de transferência é usar uma segunda máquina sob seu controle. Assim, você sabe o que está acontecendo nas duas extremidades.

Na extremidade remota:

iperf3 -s

Esse comando escuta na porta TCP 5201. Abra a porta somente para o endereço a partir do qual você fará o teste e feche-a quando terminar. Regras básicas de firewall do ufw em um VPS explica a sintaxe.

No VPS em teste:

iperf3 -c 203.0.113.10 -t 30
iperf3 -c 203.0.113.10 -t 30 -R
iperf3 -c 203.0.113.10 -t 30 -P 8

O primeiro comando mede o upload da máquina em teste. -R inverte a direção e mede o download. -P 8 abre oito fluxos paralelos.

Execute tanto o fluxo único quanto a versão paralela, porque eles respondem a perguntas diferentes. Uma conexão TCP só pode manter uma quantidade de dados não confirmados equivalente ao permitido pela janela. Portanto, o limite é aproximadamente o tamanho da janela dividido pelo tempo de ida e volta. Com latência de 80 ms e uma janela de 4 MB, esse limite é de aproximadamente 400 Mbit/s, independentemente da velocidade do link subjacente. O valor do fluxo único mostra o que um download obterá. O valor paralelo mostra a capacidade do link.

Monitore seu limite de banda durante os testes. Trinta segundos a 1 Gbit/s transferem aproximadamente 3.75 GB, e você executará o teste várias vezes em cada direção.

Números de referência e como interpretar os seus

[
  {
    "device": "Local NVMe",
    "iops_4k_read": "180,000"
  },
  {
    "device": "Local SATA SSD",
    "iops_4k_read": "90,000"
  },
  {
    "device": "Network block",
    "iops_4k_read": "12,000"
  },
  {
    "device": "Spinning disk",
    "iops_4k_read": "180"
  }
]

Um volume NVMe local normalmente atinge cerca de 180,000 IOPS de leitura aleatória 4k nos resultados publicados. Um SSD SATA local fica em torno de 90,000. O armazenamento de blocos conectado à rede, no qual cada solicitação atravessa a rede antes de chegar ao disco, fica mais próximo de 12,000, enquanto um disco rígido alcança aproximadamente 180, porque move uma cabeça física para cada solicitação aleatória.

Esses são números publicados típicos de cada classe de armazenamento, não medições feitas em um único host. Use-os para uma finalidade: verificar se o seu resultado está na ordem de grandeza correta. Se um plano vendido como NVMe apresentar poucos milhares de IOPS de leitura aleatória 4k no benchmark, confirme primeiro se --direct=1 estava ativado. Se estava, então o armazenamento não corresponde ao que a página do produto descreve, ou você está compartilhando-o com um vizinho muito ocupado.

Por que uma execução não é um benchmark

Um único resultado é um instantâneo de um minuto em uma máquina compartilhada. Trate-o como uma amostra.

• Execute cada teste pelo menos cinco vezes, distribuídas em horários diferentes e em pelo menos dois dias diferentes. Mantenha a mediana e a dispersão. Um resultado publicado sem dispersão é um número de marketing.
• Registre o tempo de steal ao lado de cada execução. Descarte as execuções em que st estava alto ou, no mínimo, observe esse fato.
• Execute o teste de disco com duas durações. Muitos planos oferecem uma cota de IOPS de burst que é reposta com o tempo, portanto uma execução de 60 segundos do fio mede o burst, enquanto --runtime=600 mede o limite inferior. O limite inferior é o desempenho obtido em um dia ruim.
• Verifique se nada mais está em execução. unattended-upgrades iniciar uma transação do apt no meio de um teste de CPU reduz sua pontuação real, e ps -e -o comm= | grep -E 'apt|dpkg' antes de cada execução leva um segundo.
• Altere uma variável por vez. Versões diferentes das ferramentas, tamanhos de bloco ou contagens de threads produzem números que não podem ser comparados, por mais semelhantes que pareçam.

Ao comparar dois provedores, execute os testes no mesmo horário do mesmo dia. Caso contrário, você terá medido o horário do dia.

Avalie sua própria carga por último

As ferramentas sintéticas classificam as máquinas. Somente sua própria carga informa se uma máquina é suficiente. Cronometre a tarefa que você realmente executa.

time tar -czf /tmp/bench.tgz /usr/share
rm -f /tmp/bench.tgz

Isso compacta algumas centenas de megabytes, portanto exercita CPU e disco ao mesmo tempo e varia quando qualquer um deles muda. O aviso Removing leading / from member names é normal. Melhor ainda é cronometrar seu próprio build, sua própria consulta mais lenta ou sua própria renderização de página. Um build que leva 4 minutos em um host e 7 em outro resolve a questão, independentemente do que o Geekbench indicou. Essa também é a medição que informa quando deixar de pagar por uma máquina mais potente, algo importante saber antes de ler quanto um VPS realmente custa por mês ou mover a carga para um servidor dedicado.

FAQ

Por que obtenho um resultado de benchmark diferente toda vez que o executo?

Um VPS compartilha CPU física, armazenamento e rede com outros clientes. Por isso, o resultado depende do que eles estão fazendo naquele momento. Execute vmstat 1 durante o teste e leia a coluna st: um steal time sustentado acima de 5 indica que o host estava ocupado, e sua pontuação de CPU é baixa por motivos externos à sua máquina. A solução é usar um método consistente, não fazer ajustes. Execute cada teste cinco vezes ou mais em horários diferentes. Depois, informe a mediana junto com a variação dos resultados.

Por que o fio informa milhões de IOPS?

Quase sempre porque --direct=1 está ausente. Sem essa opção, o fio lê por meio do cache de páginas do kernel. Assim, após a primeira passagem, um arquivo de teste de 2G é servido pela RAM, e você mediu a largura de banda da memória. Adicione --direct=1 e mantenha o arquivo de teste maior que qualquer cache no caminho. Se --direct=1 falhar com err=-1/file:ioengines.c:321, func=get_events, error=Unknown error -1, execute df -hT .: um Type de overlay não oferece suporte a O_DIRECT. Nesse caso, direcione o teste para o armazenamento real.

O yabs.sh é suficiente por si só?

Para uma primeira avaliação, sim. Ele executa o fio com quatro tamanhos de bloco, o iperf3 nas duas direções e o Geekbench. Também exibe um resumo que outras pessoas conseguem interpretar. Ele deixa de ser suficiente quando você quer saber por que um número tem determinado valor, porque não é possível variar suas opções em cada teste. Quando um resultado do yabs parecer incorreto, reproduza-o diretamente com fio ou sysbench e altere uma opção por vez.

Qual único número prevê como minha aplicação vai se comportar?

A velocidade de CPU em single core e a latência de leitura aleatória 4k, nessa ordem, para a maioria das cargas de trabalho web e de banco de dados. Números de throughput parecem impressionantes, mas raramente determinam alguma coisa, porque uma requisição típica é pequena. Informe o percentil 99 do bloco clat percentiles do fio em vez da média. A única requisição lenta em cada cem é a que o usuário percebe.

Preciso instalar alguma coisa antes de executar o benchmark?

fio, sysbench e iperf3 estão disponíveis nos repositórios do Ubuntu e do Debian: sudo apt install -y fio sysbench iperf3. yabs.sh precisa apenas de curl, porque baixa binários estáticos para tudo o que estiver ausente. Exclua todos os arquivos de teste ao terminar. Um arquivo do fio de 2G deixado em um disco de 20G pode gerar um alerta de disco cheio semanas depois.