Como fazer benchmark de VPS corretamente com yabs.sh

O que significa fazer benchmark de um VPS

Para fazer benchmark de um VPS, meça quatro aspetos: a velocidade de execução de um único núcleo de CPU, a largura de banda da memória, o número de operações de disco aleatórias pequenas que o armazenamento processa por segundo e o throughput fornecido pela ligação de rede. Uma execução de yabs.sh fornece os quatro resultados em cerca de dez minutos. Interpretar o resultado é a parte mais difícil, porque um VPS (servidor privado virtual) partilha o hardware físico com outros utilizadores. Por isso, a mesma máquina pode apresentar 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 baixo dele. Executá-las diretamente permite alterar uma flag, observar como o valor muda e perceber o que esse valor estava realmente a medir. Faça isto depois de configurar a máquina, não antes. Os passos em os primeiros dez minutos num VPS novo vêm primeiro, porque uma máquina que ainda está a aplicar a primeira ronda de atualizações apresenta resultados de benchmark fracos por razões que não têm relação com o hardware.

Analise a máquina antes de fazer medições

Metade de todos os benchmarks incorretos resulta de uma máquina que o autor não compreendeu.

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

Hypervisor vendor: KVM significa virtualização completa, portanto, executa o seu próprio kernel. A presença de lxc ou openvz na saída de systemd-detect-virt significa virtualização por contentor: partilha o kernel do host, e os limites de CPU e memória são definições de cgroup (control group), não hardware virtual. Num sistema com cgroup v2, pode ler diretamente o limite de CPU.

cat /sys/fs/cgroup/cpu.max

max 100000 significa que não existe quota. 200000 100000 significa que pode usar 200000 microssegundos de CPU em cada período de 100000 microssegundos, o equivalente à quota de dois cores. Um plano anunciado como 4 vCPU com uma quota de dois cores nunca terá um resultado equivalente ao de quatro cores, e nenhuma ferramenta de benchmark apresenta uma linha a explicar o motivo.

df -hT / é importante por outro motivo: a coluna Type. Se apresentar overlay, está dentro de um contentor, e o teste de disco abaixo precisa de uma alteração. Tome nota disso agora.

Monitore o steal time durante todo o teste

Steal time é a percentagem de tempo em que a sua CPU virtual estava pronta para executar, mas o hypervisor atribuiu o núcleo físico a outra máquina virtual. É o sinal individual mais útil para indicar que um resultado está relacionado com os vizinhos, e não com o 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á sobrecarregado nesse momento. Nesse caso, todos os valores de CPU registados durante esse intervalo ficam baixos, sem que exista um problema na sua máquina. top apresenta o mesmo valor que %st na linha da CPU. Mantenha vmstat 1 em execução numa segunda sessão SSH enquanto executa o benchmark e registe o valor de steal junto de cada resultado.

Comece com yabs.sh

yabs.sh (Yet Another Bench Script) é um script shell que descarrega binários estáticos de fio, iperf3 e Geekbench, executa-os e apresenta um único resumo. É 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.

A forma de uma linha indicada pelo próprio projeto é esta.

curl -sL yabs.sh | bash

Isto envia diretamente para uma shell o conteúdo atualmente disponibilizado pelo URL. Descarregue o ficheiro, leia-o e só depois o execute.

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

As flags são colocadas depois de -s -- quando usa um pipe, ou diretamente depois do nome do ficheiro quando executa uma cópia local. As 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 do iperf3, -j apresenta os resultados em JSON e -w results.json grava esse JSON num ficheiro.

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

Há duas coisas que deve saber antes da primeira execução. O Geekbench envia o seu resultado e apresenta um URL público em browser.geekbench.com. Qualquer pessoa que tenha essa ligação pode consultar o modelo do CPU e as pontuações. -g ignora completamente esse teste. Em segundo lugar, a etapa do iperf3 gera tráfego real para servidores em várias regiões, que é contabilizado no limite mensal de largura de banda. Numa ligação de 1 Gbit/s, uma etapa de rede completa pode transferir dezenas de gigabytes. Por isso, use -r quando o limite for reduzido e -i numa ligação com tráfego medido.

O que significa cada parte da saída do yabs

A seção de disco executa o fio com uma combinação de leitura e escrita 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 para cada tamanho. A linha 4k é a mais importante para um banco de dados, um servidor de e-mail ou qualquer serviço que faça muitas escritas pequenas, porque a maior parte do IO dos servidores é pequena e dispersa. A linha 1m é relevante para backups e vídeo, quando são transferidas 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 e usando fluxos paralelos. Considere um número baixo como uma questão, não como uma conclusão, porque os servidores públicos de iperf3 são partilhados e frequentemente estão saturados. Por isso, um resultado fraco pode ser causado pelo ponto remoto.

A seção do Geekbench apresenta uma pontuação para um núcleo e outra para vários núcleos. O resultado de um núcleo indica a rapidez com que um pedido, uma compilação ou uma consulta termina. O resultado de vários núcleos indica principalmente quantos núcleos foram realmente disponibilizados para si.

Disco: execute o fio diretamente

O fio (flexible IO tester) é a ferramenta usada pela secção de disco do yabs, e executá-lo diretamente é o que dá significado às flags.

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 ficheiros que realmente pretende 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 deve ler na saída tem este aspeto.

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

Abaixo dela, o fio apresenta um bloco clat percentiles. O percentil 99.00 é o valor que deve citar, porque indica quanto tempo demorou o pedido mais lento em cada grupo de 100 pedidos. Uma latência média oculta precisamente as esperas que o utilizador nota.

• --direct=1 abre o ficheiro com O_DIRECT, para que as leituras ignorem a cache de páginas do kernel. Sem essa opção, a segunda passagem por um ficheiro de 2G numa máquina com 8G de RAM é servida a partir da memória, e o fio apresenta IOPS na ordem dos milhões. Esse valor é real, mas representa a memória.
• --ioengine=libaio submete pedidos assíncronos, permitindo que --iodepth=32 mantenha 32 pedidos em execução. Com um mecanismo síncrono como psync, uma profundidade de fila superior a 1 não produz qualquer efeito, e mede apenas um pedido de cada vez.
• --time_based --runtime=60 executa o teste durante 60 segundos fixos, em vez de uma quantidade fixa de trabalho. Assim, um disco rápido e um disco lento usam o mesmo tempo de relógio, e a comparação mantém-se justa.
• --size=2G define o tamanho do ficheiro de teste. Mantenha-o superior a qualquer cache existente no caminho e confirme primeiro se tem espaço livre suficiente.

A escrita aleatória usa o mesmo comando com --rw=randwrite. Execute-a separadamente e elimine o ficheiro 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 utilizada altera estes resultados mais do que qualquer flag, e essa diferença é explicada em a diferença entre armazenamento NVMe e SSD SATA numa VPS.

Quando o fio termina com Unknown error -1

A E/S direta não está disponível em todos os sistemas de ficheiros. overlay, o sistema de ficheiros que o Docker fornece por predefinição a um contentor, e vários sistemas de ficheiros de rede não suportam O_DIRECT. Por isso, o libaio submete um pedido 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 indicar overlay, aponte --filename para um caminho num armazenamento real, como um volume montado por bind, ou execute o fio no host em vez de o executar no contentor. Se não for possível aceder a armazenamento real, uma execução síncrona com buffer pelo menos confirma que o próprio 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 claro sobre o que essa execução representa. Depois da primeira passagem, o ficheiro de 256M permanece na cache de páginas, pelo que 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 do disco.

Por que dd não é um benchmark de disco

dd aparece em muitas discussões 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

Isto mede o débito de escrita sequencial com uma thread e um pedido em execução. É uma verificação básica razoável. Não diz nada sobre E/S aleatória nem sobre o que acontece quando chegam 32 pedidos ao mesmo tempo. Omita oflag=direct e, na prática, estará a medir principalmente a rapidez com que o kernel aceita as escritas na memória. Por isso, os valores de dd citados em publicações de fóruns são muitas vezes absurdos.

CPU: sysbench cpu

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

O valor a considerar é events per second. Execute primeiro com uma única thread. Esse é o valor que determina a rapidez com que um pedido PHP termina ou um trabalho de compilação é concluído, e é o que mais varia entre hosts com o mesmo preço. Em seguida, execute com todas as threads. Isso mostra se as suas vCPUs correspondem a cores separados ou a frações de um único core.

É importante entender o que este teste mede: o sysbench procura repetidamente números primos usando aritmética de inteiros de 64 bits. Não testa a largura de banda da memória, as unidades vetoriais nem a cache de uma forma semelhante a uma carga de trabalho real. Por isso, é útil para comparar dois hosts, mas não é adequado para prever o desempenho da sua aplicação.

O Ubuntu 24.04 inclui o sysbench 1.0.20, no qual o nome do teste aparece primeiro. Se copiar um comando com --test=cpu de uma publicação antiga, obterá WARNING: the --test option is deprecated. Os resultados do sysbench 0.4 e do sysbench 1.0 não são comparáveis. Nunca compare o seu resultado com um valor publicado que não indique 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 é apresentado em MiB/sec, e as leituras são mais rápidas do que as escritas em todas as máquinas. Mantenha --memory-block-size em 1M e use exatamente o mesmo valor em todos os hosts comparados. Com 1K, o valor cai drasticamente, porque o custo por operação é pago mil vezes mais, passando a medir o custo do loop em vez da largura de banda da memória. Esta é a flag mais frequentemente definida de forma diferente nos resultados de memória publicados.

Rede: iperf3

A forma correta de testar o throughput é usar uma segunda máquina que controla, porque assim sabe o que está a acontecer nas duas extremidades.

Na outra extremidade:

iperf3 -s

Este comando fica à escuta na porta TCP 5201. Abra a porta apenas para o endereço a partir do qual vai testar e feche-a quando terminar. Regras básicas de firewall do ufw numa VPS explica a sintaxe.

Na 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 como a versão paralela, porque respondem a perguntas diferentes. Uma ligação TCP só consegue manter a quantidade de dados não confirmados permitida pela sua janela. Por isso, o limite é aproximadamente o tamanho da janela dividido pelo tempo de ida e volta. Com uma latência de 80 ms e uma janela de 4 MB, esse limite é de cerca de 400 Mbit/s, independentemente da velocidade da ligação subjacente. O resultado do fluxo único mostra a velocidade obtida por um único download. O resultado paralelo mostra a capacidade da ligação.

Acompanhe o limite de tráfego incluído enquanto faz estes testes. Trinta segundos a 1 Gbit/s transferem cerca de 3.75 GB, e vai executar o teste várias vezes em cada direção.

Valores 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 apresenta normalmente cerca de 180,000 IOPS de leitura aleatória 4k nos resultados publicados. Um SSD SATA local fica perto de 90,000. O armazenamento de blocos ligado à rede, em que cada pedido atravessa a rede antes de chegar ao disco, fica mais perto de 12,000, enquanto um disco mecânico consegue aproximadamente 180, porque movimenta uma cabeça física para cada pedido aleatório.

Estes são valores publicados típicos para cada classe de armazenamento, não medições feitas num único host. Use-os apenas para confirmar se o seu resultado está na ordem de grandeza correta. Se um plano vendido como NVMe obtiver nos testes alguns milhares de IOPS de leitura aleatória 4k, confirme primeiro se --direct=1 estava ativo. Se estava, então o armazenamento não corresponde ao que a página do produto descreve ou está a ser partilhado com um vizinho muito ocupado.

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

Um único resultado é um retrato de um minuto numa máquina partilhada. Trate-o como uma amostra.

• Execute cada teste pelo menos cinco vezes, distribuídas por horas diferentes e por pelo menos dois dias diferentes. Guarde a mediana e a dispersão. Um resultado publicado sem dispersão é um valor de marketing.
• Registe o tempo de steal junto de cada execução. Descarte as execuções em que st esteve elevado ou, no mínimo, indique que isso aconteceu.
• Execute o teste de disco com duas durações. Muitos planos fornecem uma reserva de IOPS de burst que é reposta ao longo do tempo, por isso uma execução de 60 segundos do fio mede o burst, enquanto --runtime=600 mede o desempenho mínimo. O desempenho mínimo é o que obtém num dia mau.
• Confirme que não está a ser executado mais nada. unattended-upgrades iniciar uma transação do apt a meio de um teste de CPU custa pontos reais, e ps -e -o comm= | grep -E 'apt|dpkg' antes de cada execução demora um segundo.
• Altere uma variável de cada 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 fornecedores, execute os testes à mesma hora do mesmo dia. Caso contrário, mediu a hora do dia.

Avalie a sua própria carga de trabalho por último

As ferramentas sintéticas classificam as máquinas. Apenas a sua própria carga de trabalho mostra se uma máquina é suficiente. Meça o tempo da tarefa que realmente executa.

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

Isto comprime algumas centenas de megabytes, por isso exercita o CPU e o disco em conjunto e varia quando qualquer um deles muda. O aviso Removing leading / from member names é normal. Melhor ainda, meça o tempo da sua própria compilação, da sua consulta mais lenta ou da renderização da sua própria página. Uma compilação que demora 4 minutos num host e 7 noutro resolve a questão, independentemente do resultado do Geekbench. Esta é também a medição que mostra quando deixa de compensar pagar por uma máquina mais potente. É útil saber isso antes de ler quanto custa realmente um VPS por mês ou transferir a carga de trabalho para um servidor dedicado.

FAQ

Por que obtenho um resultado diferente no benchmark sempre que o executo?

Uma VPS partilha CPU, armazenamento e rede físicos com outros utilizadores, por isso o resultado depende do que eles estão a fazer nesse momento. Execute vmstat 1 durante o teste e leia a coluna st: um steal time sustentado acima de 5 significa que o host estava ocupado, e a pontuação da CPU é baixa por motivos externos à sua máquina. A solução está no método, não no ajuste fino. Execute cada teste cinco ou mais vezes em horas diferentes e comunique a mediana juntamente com a dispersão.

Por que o fio comunica milhões de IOPS?

Quase sempre porque --direct=1 está em falta. Sem essa opção, o fio lê através da page cache do kernel. Assim, depois da primeira passagem, um ficheiro de teste de 2G é servido a partir da RAM e o que foi medido foi a largura de banda da memória. Adicione --direct=1 e mantenha o ficheiro de teste maior do que qualquer cache existente no percurso. Se --direct=1 falhar então com err=-1/file:ioengines.c:321, func=get_events, error=Unknown error -1, execute df -hT .: um Type de overlay não suporta O_DIRECT, por isso aponte o teste para 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 nos dois sentidos e o Geekbench, e apresenta um resumo que outras pessoas conseguem ler. Deixa de ser suficiente quando precisa de saber por que motivo um valor é o que é, porque não pode variar as flags por teste. Quando um resultado do yabs parece incorreto, reproduza-o diretamente com fio ou sysbench e altere uma flag de cada vez.

Que valor único prevê como a minha aplicação vai responder?

A velocidade de um único core da CPU e a latência de leitura aleatória 4k, por esta ordem, para a maioria das cargas de trabalho web e de bases de dados. Os valores de throughput parecem impressionantes e raramente determinam alguma coisa, porque um pedido típico é pequeno. Apresente o percentil 99 do bloco clat percentiles do fio, em vez da média, porque o pedido lento em cada cem é aquele que o utilizador nota.

Preciso de instalar alguma coisa antes de fazer o benchmark?

fio, sysbench e iperf3 estão disponíveis nos repositórios do Ubuntu e Debian: sudo apt install -y fio sysbench iperf3. yabs.sh precisa apenas de curl, porque descarrega binários estáticos para tudo o que estiver em falta. Elimine todos os ficheiros de teste quando terminar, porque deixar um ficheiro do fio de 2G num disco de 20G pode gerar um alerta de disco cheio semanas mais tarde.