Benchmark de Storage no Proxmox: O Guia Anti-Ilusão

Chegamos à cena do crime e o relatório preliminar é sempre o mesmo: um administrador orgulhoso posta um screenshot no fórum mostrando uma velocidade de escrita de 3GB/s em um array de HDs mecânicos SATA.

"Olha como meu ZFS no Proxmox voa", diz ele.

Como investigador forense de sistemas, meu trabalho não é parabenizar; é encontrar a fraude. E nesse caso, a fraude não é maliciosa, é autoengano. Aquele número não é a velocidade do disco. É a velocidade da memória RAM. O administrador não testou o storage; ele testou o cache.

Para entender a performance real de I/O em virtualização, precisamos dissecar o sistema, isolar variáveis e, principalmente, parar de acreditar em mentiras confortáveis. Vamos começar a autópsia.

A Falácia do dd: O Falso Positivo

A ferramenta dd é onipresente, fácil de usar e, para benchmarks de storage moderno, quase inútil. O comando clássico dd if=/dev/zero of=testfile bs=1G count=1 é o equivalente a medir a velocidade de um carro levantando-o em um elevador e pisando no acelerador. O velocímetro marca 200km/h, mas o carro não saiu do lugar.

Por que o dd mente para você?

1. Compressibilidade: Ele escreve zeros (/dev/zero). Se você usa ZFS com compressão (LZ4/ZSTD), o sistema de arquivos detecta a sequência de zeros, comprime isso para quase nada e diz "concluído" sem quase tocar no disco físico. Você mediu sua CPU, não seu disco.

2. Assincronia: Por padrão, o dd joga os dados no Page Cache do sistema operacional (RAM) e retorna o prompt. O dado ainda não está no disco.

Se você vê números que desafiam a física da interface SATA/SAS/NVMe, você está vendo um "cache hit".

Anatomia do I/O: O Caminho Tortuoso

Para medir corretamente, você precisa entender a jornada que um bloco de dados faz. Em um ambiente Proxmox (KVM), o buraco é muito mais embaixo do que em um bare metal.

Quando uma aplicação dentro da VM pede para gravar um arquivo, o dado atravessa um labirinto burocrático:

1. User Space (VM): A aplicação faz a syscall write().

2. Kernel (VM): O Linux da VM joga isso no Page Cache virtualizado e no driver de disco (geralmente VirtIO).

3. Hypervisor (QEMU): O processo QEMU no host intercepta essa chamada.

4. Kernel (Host): O Proxmox recebe o pedido. Aqui entra o ZFS (ARC) ou LVM.

5. Hardware: Finalmente, o controlador manda o pulso elétrico para o disco gravar magneticamente ou na célula NAND.

Figura: O Labirinto do I/O: Seu dado atravessa todas essas barreiras. Cada uma adiciona latência e locais para cache.

Cada barreira dessa imagem adiciona latência. E pior: cada barreira tem seu próprio mecanismo de cache, pronto para interceptar a gravação e dizer "já terminei" antes da hora.

A Guerra contra o Cache: Furando o ARC e o Page Cache

O cache existe para fazer o sistema parecer mais rápido em uso normal. Mas em um benchmark, o cache é o inimigo. Ele mascara os gargalos reais. Se o seu servidor de banco de dados travar e reiniciar, o que estava no cache desapareceu. O que importa para a integridade dos dados (e para benchmarks sérios) é a velocidade de Sync Write (escrita síncrona) ou a velocidade após o cache encher.

Se o seu teste dura 10 segundos e você tem 64GB de RAM, você não testou o disco. Você apenas encheu uma piscina olímpica com um copo d'água.

Figura: O Abismo do Cache: Se o seu teste não dura tempo suficiente para estourar a RAM (ARC + Page Cache), você está medindo a velocidade da sua memória, não do seu disco.

Para obter a verdade nua e crua, precisamos garantir duas coisas:

1. Bypass de Cache: Usar flags como O_DIRECT ou fsync para forçar o dado a ir até o disco.

2. Saturação: O tamanho do teste deve ser pelo menos 2x o tamanho da RAM disponível (ARC + Page Cache da VM). Se você tem 32GB de RAM, seu teste deve escrever 64GB ou mais.

Fio: O Bisturi do Engenheiro

Abandone o dd. A ferramenta padrão da indústria para "tortura controlada" de storage é o fio (Flexible I/O Tester). Ele permite simular cargas de trabalho reais, em vez de apenas copiar zeros.

Não copie e cole comandos sem entender. Aqui estão os parâmetros vitais para sua investigação:

• ioengine=libaio: O motor de I/O. O padrão do Linux para alta performance assíncrona.

• direct=1: A pílula da verdade. Ignora o buffer/cache do sistema operacional da VM.

• bs (Block Size): O tamanho do pacote.

  • 4k: Simula bancos de dados, logs, metadados. Brutal para HDs mecânicos.
  • 1M/4M: Simula backups, streaming de vídeo. Mais fácil para o disco.

• iodepth: Quantos pedidos estão na fila ao mesmo tempo.

  • 1: Latência pura. Como uma thread única operando.
  • 32 ou mais: Throughput máximo. Tenta saturar o cabo.

• numjobs: Quantos processos simultâneos.

Protocolo de Teste: O Comando Real

Aqui está um exemplo de comando fio para rodar dentro da VM que busca a verdade sobre a performance de escrita aleatória (o pior cenário possível):

fio --name=teste_autopsia \
    --ioengine=libaio \
    --rw=randwrite \
    --bs=4k \
    --direct=1 \
    --size=10G \
    --numjobs=4 \
    --iodepth=32 \
    --group_reporting \
    --runtime=60 \
    --time_based

O que estamos procurando aqui? Não olhe apenas para o MB/s. Olhe para o IOPS e, crucialmente, para a latência (clat). Se o IOPS for alto mas a latência for de 500ms, seu banco de dados ficará inutilizável, mesmo que o "número de velocidade" pareça alto.

Olhando de Fora: Monitorando o Host enquanto a VM sofre

Um erro clássico é confiar apenas no output do fio dentro da VM. A VM vive numa Matrix; a realidade está no Host (Proxmox).

Enquanto o teste roda na VM, abra o shell do Proxmox e monitore o que o hardware está realmente sentindo.

1. Latência de Disco Físico

Use o iostat para ver se os discos físicos estão saturados.

# No shell do Proxmox Host
iostat -x 1

Fique atento à coluna %util (perto de 100% significa gargalo) e w_await (tempo de espera para escrita). Se w_await estiver em milissegundos de dois ou três dígitos, seus discos estão gritando.

2. O Comportamento do ZFS

Se você usa ZFS, veja se o ARC está sendo drenado ou ignorado.

# No shell do Proxmox Host
zpool iostat -v 1

Isso mostrará a vazão real descendo para os vdevs. Se o fio na VM diz 500MB/s, mas o zpool iostat mostra 0MB/s de escrita, parabéns: você está medindo cache, e seu teste é inválido.

Contexto é Rei: Diferenciando Cargas

Não existe "storage rápido" no vácuo. Existe storage adequado para a carga de trabalho. Um storage otimizado para ISOs (sequencial) vai falhar miseravelmente rodando PostgreSQL (aleatório).

Carga de Trabalho	O que importa	Parâmetros fio sugeridos	O Perigo
Banco de Dados (OLTP)	IOPS em 4k, Latência de Sync	bs=4k, rw=randwrite, fsync=1	Ignorar latência de fsync (ZIL/SLOG).
Media Server (Plex)	Throughput Sequencial	bs=1M, rw=read, iodepth=4	Focar em IOPS (inútil aqui).
File Server (Geral)	Misto	bs=64k a 1M, rw=rw	Testar apenas leitura e esquecer a escrita.

O Veredito Forense

Ao finalizar seu benchmark, você não deve ter apenas um número ("500 MB/s"). Você deve ter uma narrativa causal:

"O sistema sustenta 4.000 IOPS em escrita aleatória 4k com latência sub-2ms, limitado pela velocidade de rotação dos discos, confirmado pela saturação de 100% no iostat do host. O cache ARC absorveu os primeiros 10GB, mas a performance estabilizou no patamar real do hardware após 40 segundos de teste."

Isso é evidência. O resto é ilusão.