loadtest.appda LoadFocus

Guias

Como usar o sysbench: benchmarks de CPU, disco e MySQL

7 min de leitura

O sysbench é uma ferramenta de benchmark open source e multithread, construída sobre LuaJIT, que traz testes de CPU, memória, E/S de arquivos, threads e mutex, além de scripts OLTP para MySQL e PostgreSQL. Os testes que precisam de dados seguem o mesmo ciclo: prepare cria os arquivos ou as tabelas de teste, run executa o benchmark por um tempo ou número de eventos definido, e cleanup apaga os dados; os testes de CPU e memória só precisam de run. Ele mede uma única máquina ou um único servidor de banco de dados, então não diz como a sua aplicação se comporta com tráfego real de usuários.

Não rodamos o sysbench para este guia. Os fatos vêm do README e do código-fonte no branch master do GitHub, conferidos em 31 de outubro de 2026, e as recomendações são nossas.

Temasysbench
LicençaGPLv2
Escrito emC, com LuaJIT para os scripts
Última versão1.0.20 (24 de abril de 2020)
Último commit9 de março de 2025
Testes embutidoscpu, memory, fileio, threads, mutex
Scripts de banco de dadosOito scripts oltp_*, bulk_insert, dois select_random_*
Drivers de banco de dadosMySQL (padrão), PostgreSQL
PlataformasLinux, macOS; Windows via WSL

O sysbench ainda é mantido?

Pouco. A última versão, 1.0.20, saiu em abril de 2020; desde então o branch master recebeu commits ocasionais, nenhum deles lançado numa versão, o mais recente em março de 2025.

A versão 1.0.20 tem data de 24 de abril de 2020. O histórico de commits mostra mudanças como uma distribuição uniforme por padrão para --rand-type (2020), um LuaJIT do upstream (2023) e suporte às bibliotecas cliente do MariaDB (2023), depois quatro commits de build em 9 de março de 2025 (conferido em 31 de outubro de 2026). Os repositórios de pacotes citados no README são atualizados a cada versão, então essas mudanças exigem um build a partir do código-fonte.

Como funciona uma execução do sysbench?

Você informa um teste e um comando: sysbench [options] [testname] [command]. O teste é um dos embutidos, um script Lua incluído ou o seu próprio script, e o comando costuma ser prepare, run, cleanup ou help.

Segundo o README, prepare cria os arquivos do fileio ou preenche o banco para os scripts OLTP, cleanup apaga esses dados e sysbench <testname> help lista as opções de um teste. Um teste de disco:

sysbench fileio --file-total-size=8G prepare
sysbench fileio --file-total-size=8G \
  --file-test-mode=rndrw --time=300 run
sysbench fileio --file-total-size=8G cleanup

O código do fileio lista os modos seqwr, seqrewr, seqrd, rndrd, rndwr e rndrw, com 2 GB de arquivos por padrão. Arquivos que cabem na memória podem ser servidos pelo cache de páginas, então use um total maior que a RAM quando quiser medir o disco.

Como medir CPU e memória com o sysbench?

Com sysbench cpu run e sysbench memory run. O teste de CPU informa eventos por segundo, em que um evento verifica se cada número até um limite é primo, e o teste de memória informa operações e MiB transferidos por segundo.

sysbench cpu --cpu-max-prime=20000 \
  --threads=4 --time=60 run

O teste de CPU usa --cpu-max-prime igual a 10000 por padrão, e o teste de memória aceita tamanho de bloco, tamanho total, operações de leitura ou escrita e acesso sequencial ou aleatório (conferido em 31 de outubro de 2026). Compare só execuções com configurações idênticas.

Como testar MySQL ou PostgreSQL com o sysbench?

Escolha um dos scripts OLTP incluídos, preencha as tabelas com prepare, rode transações a partir de várias threads com run e depois apague as tabelas com cleanup. O MySQL é o driver padrão; o PostgreSQL exige --db-driver=pgsql e um build com suporte a PostgreSQL.

sysbench oltp_read_write --mysql-host=10.0.0.5 \
  --mysql-user=sbtest --mysql-password=secret \
  --tables=10 --table-size=1000000 prepare
sysbench oltp_read_write --mysql-host=10.0.0.5 \
  --mysql-user=sbtest --mysql-password=secret \
  --tables=10 --table-size=1000000 \
  --threads=16 --time=300 --report-interval=10 run

O script OLTP comum cria uma tabela de 10.000 linhas se você não passar --tables e --table-size. No oltp_read_write, cada transação roda 10 consultas por chave, quatro consultas por intervalo, dois updates e um delete seguido de um insert, entre BEGIN e COMMIT (conferido em 31 de outubro de 2026). Use mais dados que o buffer pool do servidor se quiser leituras de disco no resultado.

Quais opções do sysbench importam mais?

--threads e --time definem o tamanho e a duração de uma execução, --rate define uma taxa-alvo de eventos, e --report-interval, --percentile e --histogram decidem o que você vê.

  • --threads: threads de trabalho, 1 por padrão.
  • --time: segundos, 10 por padrão, 0 para sem limite. --events limita o número de eventos, e os dois limites valem, então combine com --time=0.
  • --warmup-time: roda primeiro sem estatísticas, para que caches frios não distorçam o resultado. Só no branch master: a versão 1.0.20 não tem essa opção.
  • --rate: média de eventos por segundo somando todas as threads; 0, o padrão, significa o mais rápido possível.
  • --report-interval: números por intervalo a cada N segundos, para mostrar travamentos.
  • --percentile: o percentil de latência exibido, 95 por padrão.
  • --histogram: um histograma de latência no fim, definido em sb_logger.c.

O sysbench usa um modelo de carga fechado ou aberto?

Fechado por padrão: um número fixo de threads dispara o próximo evento assim que o anterior termina, então um servidor lento recebe menos eventos. Com --rate, os eventos chegam no próprio ritmo, o que fica mais perto de um modelo de carga aberto.

Nosso artigo sobre o modelo de carga aberto vs fechado explica por que isso muda o que um benchmark mede. No modo padrão, um travamento também atrasa os eventos que teriam começado durante ele, e esses atrasos nunca chegam às latências: é a coordinated omission. O arquivo-fonte principal mostra que --rate põe os eventos numa fila em intervalos com distribuição exponencial, soma à latência de cada evento o tempo que ele esperou na fila e para com o erro “event queue is full” quando as threads não dão conta (conferido em 31 de outubro de 2026).

Como ler a saída do sysbench?

Comece pela vazão: eventos por segundo, ou transações e consultas por segundo nos scripts OLTP. Depois leia o bloco de latência em milissegundos: mínimo, média, máximo, o percentil escolhido (p95 por padrão) e a soma.

A versão 1.0.20 mostra, no lugar de “Throughput”, um bloco “General statistics” com o tempo total e o número total de eventos. Os nomes dos campos vêm do código do relatório de banco de dados e do arquivo-fonte principal no master, aqui sem valores:

SQL statistics:
    queries performed: read, write, other, total
    transactions, queries (N per sec.)
    ignored errors, reconnects (N per sec.)
Throughput:
    events/s (eps), time elapsed, total number of events
Latency (ms):
    min, avg, max, 95th percentile, sum
Threads fairness:
    events, execution time (avg/stddev)

Um percentil 95 deixa de fora o evento mais lento de cada vinte. Use --percentile=99 ou acrescente --histogram quando a cauda importa; nosso guia de latência de cauda explica por quê.

Quando o sysbench é a ferramenta errada?

Quando a sua pergunta é sobre a sua aplicação. Uma pontuação de CPU mostra a rapidez com que uma máquina verifica números primos, e uma execução OLTP mede o servidor de banco de dados com as tabelas e consultas do sysbench, sem o seu schema, o seu pool de conexões ou o caminho de rede.

  • Escolha o pgbench para testes nativos de PostgreSQL: a documentação do PostgreSQL descreve um cenário padrão vagamente baseado no TPC-B, além de arquivos de script próprios (conferido em 31 de outubro de 2026).
  • Escolha o HammerDB para testes no estilo TPC-C: a documentação dele cobre a carga TPROC-C, derivada do TPC-C, para SQL Server, Db2, Oracle, PostgreSQL, MariaDB e MySQL (conferido em 31 de outubro de 2026).
  • Escolha o JMeter com o sampler JDBC Request para misturar SQL e HTTP num mesmo plano de teste; o guia de planos de teste de banco de dados diz que o .jar do driver vai na pasta lib do JMeter.

A LoadFocus, que publica este site, não roda o sysbench e não consegue se conectar sozinha a MySQL ou PostgreSQL. Ela roda planos de teste JMeter e scripts k6 a partir de 25 regiões na nuvem contra a camada web ou de API que fica na frente do banco. Uma combinação útil: uma execução do sysbench para dimensionar o servidor de banco de dados e depois um teste de carga da aplicação para ver se as requisições reais chegam a esse limite.

FAQ

O sysbench ainda é mantido? Pouco. A última versão é a 1.0.20, de 24 de abril de 2020. O branch master recebeu desde então commits ocasionais, nenhum deles numa versão, o mais recente em 9 de março de 2025.

O que significa o percentil 95 na saída do sysbench? É a latência, em milissegundos, dentro da qual 95% dos eventos terminaram. 95 é o valor padrão da opção --percentile, e você pode definir outro, como 99.

O sysbench consegue fazer benchmark do PostgreSQL? Sim. Os scripts OLTP incluídos rodam contra o PostgreSQL com --db-driver=pgsql quando o sysbench foi compilado com suporte a PostgreSQL.

A LoadFocus consegue rodar o sysbench? Não. A LoadFocus roda planos de teste JMeter e scripts k6 contra sites e APIs a partir de 25 regiões na nuvem, e não se conecta diretamente a MySQL ou PostgreSQL.

Leituras relacionadas

As afirmações técnicas deste artigo não foram revisadas de forma independente.

LoadFocus team
Escrito pela equipe da LoadFocus, as pessoas por trás de um serviço de teste de carga na nuvem.