Como fazer benchmark de VPS corretamente com yabs.sh

O que significa realizar um benchmark de uma VPS

Realizar um benchmark de uma VPS consiste em medir quatro fatores: a velocidade de execução de um único núcleo de CPU, a largura de banda da memória da máquina, a quantidade de operações de disco aleatórias de pequeno porte que o armazenamento processa por segundo e a taxa de transferência da ligação de rede. Uma execução do yabs.sh fornece resultados de CPU, disco e rede em cerca de dez minutos; utilize o teste de memória separado abaixo para a largura de banda da memória. Interpretar o resultado é a parte mais complexa, pois uma VPS (servidor privado virtual) partilha hardware físico com outros inquilinos; portanto, a mesma máquina pode apresentar um valor às 03:00 e um valor muito diferente às 20:00.

O plano aqui é executar o yabs.sh para obter um panorama rápido e, em seguida, executar as ferramentas abaixo manualmente. Executá-las por conta própria permite alterar uma flag, observar a variação do número e aprender o que esse número estava realmente a medir. Faça isto após a configuração da máquina, não antes. Os passos em os primeiros dez minutos numa VPS nova devem ser realizados primeiro, pois uma máquina que ainda está a aplicar a sua primeira ronda de atualizações apresenta resultados de benchmark pobres por motivos que nada têm a ver com o hardware.

Analise a máquina antes de a medir

Metade de qualquer benchmark incorreto deve-se a 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 você executa o seu próprio kernel. systemd-detect-virt imprimir lxc ou openvz significa virtualização por contentores: você partilha o kernel do host, e os seus limites de CPU e memória são definições de cgroup (control group) em vez de hardware virtual. Num sistema cgroup v2, pode ler o limite de CPU a partir do cgroup do seu contentor; o caminho seguinte aplica-se quando esse cgroup está montado em /sys/fs/cgroup.

cat /sys/fs/cgroup/cpu.max

max 100000 significa que este cgroup não tem uma quota própria; cgroups ancestrais ainda podem impor uma. 200000 100000 significa que pode utilizar 200000 microssegundos de CPU em cada período de 100000 microssegundos, o que equivale a uma quota de dois núcleos. Um plano anunciado como 4 vCPU com uma quota de dois núcleos nunca terá o desempenho de quatro núcleos. Ferramentas de benchmark conseguem identificar essa restrição: o VoxelBench reporta quotas de CPU e sinaliza uma CPU partilhada ou limitada quando o host expõe muito mais CPUs do que o servidor pode utilizar.

df -hT / é importante por uma razão diferente: a coluna Type. Se indicar overlay, você está dentro de um contentor, e os seus resultados de disco descreverão o armazenamento que está por baixo dessa camada (overlay). Registe isso agora.

Monitore o steal time constantemente

O steal time é a parcela de tempo que a sua CPU virtual passou aguardando involuntariamente enquanto o hypervisor não a escalonava. É um sinal útil de tempo de CPU indisponível, mas não distingue vizinhos ocupados da imposição da sua cota de CPU pelo provedor.

vmstat 1 10

Leia a coluna st à direita. Um steal time sustentado significa que o tempo de CPU não estava disponível para o convidado, mas um valor acima de 5% não prova que o host está com sobrecarga. Provedores podem expor deliberadamente a imposição de cota de CPU como steal time. top mostra o mesmo valor que %st na linha de CPU. Mantenha o vmstat 1 em execução em uma segunda sessão SSH enquanto realiza 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 executa fio, iperf3 e Geekbench e apresenta um único resumo. Usa fio e iperf3 se já estiverem instalados e descarrega binários estáticos quando não estão. É a linguagem comum das discussões sobre benchmarks de VPS, por isso um resultado do yabs é a forma mais rápida de comparar resultados com outra pessoa.

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

curl -sL yabs.sh | bash

Isto encaminha diretamente para um shell o conteúdo que o URL disponibilizar nesse momento. Descarregue o ficheiro, leia-o e só 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

As flags vêm depois de -s -- quando usa um pipe, ou imediatamente depois do nome do ficheiro quando executa uma cópia local. As opções úteis são: -f ignora o teste do disco, -i ignora o teste de rede, -g ignora o Geekbench, -r reduz para três as localizações 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á dois aspetos a conhecer antes da primeira execução. O Geekbench carrega o 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 fase 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 fase de rede completa pode transferir dezenas de gigabytes. Por isso, use -r se 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 IO direta não está disponível em todos os sistemas de ficheiros. Por isso, quando o fio falha no primeiro pedido com --direct=1 definido, a IO direta é o primeiro fator a excluir. A falha pode ter este aspeto:

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 primeiro df -hT .. Um Type de overlay, o sistema de ficheiros que o Docker atribui por predefinição a um contentor, não é a causa por si só. O overlayfs passa O_DIRECT para o sistema de ficheiros subjacente e recusa-o apenas quando esse sistema de ficheiros não suporta IO direta. Por isso, --direct=1 --ioengine=libaio funciona sobre um overlay assente em ext4 ou xfs. Quando o sistema de ficheiros subjacente ao ficheiro de teste não suporta realmente IO direta, o fio normalmente indica isso ao abrir o ficheiro: fio: looks like your file system does not support direct=1/buffered=0. Nesse caso, aponte --filename para um caminho num armazenamento local real, como um volume montado por bind, ou execute o fio no host em vez de o executar no contentor. Se não tiver acesso a armazenamento real, uma execução síncrona com buffer permite pelo menos confirmar 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 claro sobre o que essa execução mede. Após a primeira passagem, o ficheiro de 256M fica 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 os flags são interpretados corretamente. Nunca o apresente como um resultado do disco.

Por que o dd não é uma ferramenta de benchmark de disco

dd aparece em muitos tópicos sobre VPS e responde a apenas uma questão limitada.

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 escrita sequencial com uma thread e um pedido em trânsito. É um teste de sanidade razoável. Não diz nada sobre E/S aleatória, nem sobre o que acontece quando 32 pedidos chegam ao mesmo tempo. Remova oflag=direct e as escritas passam pelo cache de página, mas conv=fdatasync ainda força a gravação dos dados de saída no armazenamento antes de o comando terminar. Remova isso também e o resultado pode medir, em grande parte, a rapidez com que o seu kernel aceita escritas na memória, razão pela qual os valores de dd citados em fóruns são frequentemente 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. Este é o número que determina a rapidez com que um pedido PHP termina ou uma tarefa de compilação é concluída, e é o que mais varia entre hosts com o mesmo preço. Em seguida, execute com todas as threads, o que mostra como o throughput escala através das suas vCPUs alocadas.

Seja claro sobre o que isto mede: o sysbench cpu encontra repetidamente números primos por divisão experimental. Para cada candidato, calcula a raiz quadrada de precisão dupla e, em seguida, testa os divisores com módulo de inteiro de 64 bits, comparando cada divisor com esse limite de vírgula flutuante. Portanto, mistura trabalho de inteiros e de vírgula flutuante. Não sobrecarrega a largura de banda da memória, unidades vetoriais ou cache de qualquer forma que se assemelhe a uma carga de trabalho real, por isso é bom para classificar dois hosts e mau para prever como a sua aplicação irá comportar-se.

O Ubuntu 24.04 disponibiliza o sysbench 1.0.20, onde o nome do teste aparece primeiro. Se copiar um comando com --test=cpu de um post antigo, obterá WARNING: the --test option is deprecated. As pontuações do sysbench 0.4 e do sysbench 1.0 não são de todo comparáveis, por isso nunca se compare com um número publicado que não indique a sua versão.

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. Mantenha o --memory-block-size em 1M e garanta que este valor seja idêntico em todos os hosts que comparar. Em 1K, o número colapsa, pois o custo por operação é multiplicado mil vezes, fazendo com que você meça o custo do loop em vez da largura de banda da memória. Esta é a flag mais frequentemente configurada de forma inconsistente em 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.

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 em resultados publicados atinge geralmente cerca de 180,000 IOPS de leitura aleatória 4k. Um SSD SATA local situa-se em torno de 90,000. O armazenamento em bloco ligado à rede, onde cada pedido atravessa uma rede antes de chegar ao disco, situa-se mais próximo de 12,000, e um disco rígido mecânico gere aproximadamente 180, uma vez que desloca uma cabeça física para cada pedido aleatório.

Estes são valores típicos publicados para cada classe de armazenamento, não medições de um único host. Utilize-os para um único propósito: verificar se o seu próprio resultado está na ordem de grandeza correta. Se um plano comercializado como NVMe apresentar benchmarks na casa dos milhares baixos de IOPS 4k, confirme primeiro se o --direct=1 estava ativado. Se estava, verifique os limites de IOPS e os créditos de burst do plano, bem como a contenção de armazenamento e o hardware anunciado.

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

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

• Execute cada teste pelo menos cinco vezes, distribuídas por horas diferentes e pelo menos dois dias diferentes. Mantenha a mediana e a dispersão. Um resultado publicado sem uma dispersão é um número de marketing.
• Registe o steal time ao lado de cada execução. Mantenha as execuções onde o st foi elevado e investigue se refletem contenção ou a quota de CPU do plano; descartá-las pode ocultar o desempenho que realmente recebe.
• Execute o teste de disco com duas durações. Muitos planos oferecem uma tolerância de IOPS de burst que é reposta ao longo do tempo, mas nem uma execução de 60 segundos do fio nem o --runtime=600 garantem que mediu o limite mínimo. Os créditos gp2 da AWS podem sustentar 3.000 IOPS durante pelo menos 30 minutos a partir de um saldo total, portanto, ambas as execuções podem medir o desempenho de burst. Verifique o modelo de crédito do fornecedor e monitorize o saldo de crédito antes de classificar um resultado como desempenho sustentado.
• Verifique se não há mais nada a correr. O unattended-upgrades iniciar uma transação apt a meio de um teste de CPU custa-lhe pontos reais, e o ps -e -o comm= | grep -E 'apt|dpkg' antes de cada execução demora um segundo.
• Altere apenas uma variável de cada vez. Versões de ferramentas, tamanhos de bloco ou contagens de threads diferentes produzem números que não podem ser comparados, independentemente de quão semelhantes pareçam.

Ao comparar dois fornecedores, execute-os à mesma hora do mesmo dia. Caso contrário, mediu apenas 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 de benchmark diferente cada vez que o executo?

Uma VPS partilha CPU físico, armazenamento e rede com outros inquilinos, por isso o seu resultado depende do que eles estão a fazer nesse momento. Execute vmstat 1 durante o teste e leia a coluna st: o "steal time" sustentado regista o tempo de CPU indisponível, mas pode refletir tanto o fornecedor a impor a alocação de CPU contratada como a contenção no host. Um valor acima de 5% não estabelece a causa. A resposta reside no método e não em ajustes. Execute cada teste cinco ou mais vezes em horas diferentes e, em seguida, reporte a mediana juntamente com a dispersão.

Por que é que o fio reporta milhões de IOPS?

Quase sempre porque falta o --direct=1. Sem ele, o fio lê através da cache de página do kernel, pelo que, após a primeira passagem, um ficheiro de teste de 2G é servido a partir da RAM e mediu a largura de banda da memória. Adicione --direct=1 e mantenha o ficheiro de teste maior do que qualquer cache no caminho. Se o --direct=1 falhar, execute df -hT . e verifique onde o ficheiro de teste está alojado. Um tipo overlay não é o problema por si só, porque o overlayfs passa o O_DIRECT para o armazenamento subjacente. Mova o ficheiro de teste para armazenamento local real apenas se o sistema de ficheiros subjacente recusar o IO direto.

O yabs.sh é suficiente por si só?

Para uma primeira análise, sim. Executa o fio em quatro tamanhos de bloco, o iperf3 em ambas as direções e o Geekbench, e imprime um resumo que outras pessoas podem ler. Deixa de ser suficiente quando quer saber por que um número é o que é, porque não pode variar as suas flags por teste. Assim que um resultado do yabs parecer incorreto, reproduza-o diretamente com o fio ou sysbench e altere uma flag de cada vez.

Que número único prevê como a minha aplicação se comportará?

A velocidade de um único núcleo de CPU e a latência de leitura aleatória 4k, por esta ordem, para a maioria das cargas de trabalho de web e base de dados. Os números de throughput parecem impressionantes, mas raramente decidem algo, porque um pedido típico é pequeno. Cite o percentil 99 do bloco clat percentiles do fio em vez da média, uma vez que o pedido lento, um em cada cem, é o que um utilizador nota.

Preciso de instalar algo antes de fazer o benchmark?

O fio, o sysbench e o iperf3 estão todos nos repositórios do Ubuntu e Debian: sudo apt install -y fio sysbench iperf3. O yabs.sh é executado em Bash e precisa de curl ou wget para transferências, além do tar para extrair o Geekbench; sem o tar, ele ignora o Geekbench. Utiliza o fio e o iperf3 quando estão instalados e descarrega binários estáticos quando estão em falta. Elimine todos os ficheiros de teste quando terminar, uma vez que um ficheiro de 2G do fio deixado num disco de 20G torna-se o alerta de disco cheio de alguém semanas mais tarde.