Quando o storage derruba seu servidor

Pense nessa ocasião: você aprova um servidor corporativo com CPU “de sobra”, a VM sobe rápido e, na primeira semana, o ERP começa a “engasgar” sem motivo aparente.

O que quase ninguém te conta no comitê de compra é simples: em servidores para empresas, performance não é sobre o “processador mais forte”, e sim sobre o caminho completo do dado (CPU → memória → rede → storage → aplicação).

Se você quer evitar o clássico “CPU forte, storage fraco”, faça isso antes de ir para produção:

1) Defina a métrica que manda no seu workload: latência p95, não “média”.
2) Meça I/O por tipo: leitura, escrita, aleatório e sequencial.
3) Valide fila de disco e tempo de espera por I/O no SO/hipervisor.
4) Rode teste sintético (fio/DiskSpd) com bloco e profundidade de fila parecidos com o real.
5) Faça um “go/no-go” com critérios numéricos de latência e throughput.

Régua técnica para projetos de servidor empresarial: se você não consegue explicar “qual latência p95 aceitamos” e “qual IOPS precisamos”, você ainda está comprando no escuro, mesmo com a melhor CPU do mundo.

O erro clássico: medir só CPU e RAM

CPU é fácil de vender porque é visível: núcleos, GHz, geração. Storage é onde a dor aparece porque “parece detalhe” até a aplicação entrar em carga.

Na prática, o gargalo se manifesta como:

• Usuário reclamando de lentidão “intermitente” (picos).
• Banco de dados com tempo de resposta irregular.
• Backup que invade janela de produção.
• VM com CPU baixa, mas travando em I/O wait.

Isso é contraintuitivo para muita liderança: CPU ociosa não significa folga; pode significar que a CPU está esperando o storage.

Métrica que separa “tá ok” de “vai dar problema”

Use latência p95 (ou p99) do storage. A média esconde picos que quebram experiência e SLAs.

Para referência de observabilidade e troubleshooting, veja contadores e boas práticas do Windows e do ecossistema de performance:

• Microsoft (contadores/visão de disco): https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/typeperf
• VMware (visão de latência e performance em vSphere): https://docs.vmware.com/en/VMware-vSphere/index.html
• SNIA (fundamentos e padronização de storage): https://www.snia.org/education

Tutorial técnico: como identificar “CPU forte, storage fraco” antes do go-live

Vamos para um caminho bem objetivo, do tipo que um Coordenador de TI consegue aplicar em projeto e o CEO entende como redução de risco.

Passo 1 — Descreva o workload com 4 números

Sem isso, você só tem opinião. Com isso, você tem especificação.

4 números mínimos:

• IOPS (leitura e escrita).
• MB/s (throughput).
• tamanho de bloco (ex.: 4K, 8K, 64K).
• latência p95 alvo (em ms).

Exemplo prático: se seu banco trabalha com páginas de 8 KB, testar só com 64 KB dá uma falsa sensação de throughput alto e latência “bonita”.

Passo 2 — Use uma fórmula simples 

Quando o fornecedor fala “X GB/s”, pergunte: em qual tamanho de bloco?

Fórmula útil:

IOPS ≈ (MB/s × 1024) ÷ (Bloco em KB)

Exemplo ilustrativo: 800 MB/s com bloco de 8 KB ≈ (800×1024)/8 ≈ 102.400 IOPS. Parece muito, mas só vale se a latência p95 ficar dentro do alvo e se o perfil for compatível (sequencial vs aleatório).

Passo 3 — Rode teste sintético com parâmetros 

Para ambientes Linux, fio é comum. Para Windows, DiskSpd costuma ser a escolha. O ponto não é a ferramenta, e sim a disciplina:

• Defina mix (70/30 leitura/escrita, por exemplo) conforme a aplicação.
• Ajuste iodepth (fila) para simular concorrência.
• Colete latência p95/p99, não só throughput.

Se você só reporta “MB/s”, você está testando cópia de arquivo, não transação.

Passo 4 — Valide onde o gargalo nasce (fila, cache, rede ou disco)

Um gargalo “parecido com storage” pode ser:

• rede saturada entre host e storage (ou entre nós).
• cache insuficiente para o padrão de leitura.
• RAID/paridade mal dimensionado para escrita aleatória.
• discos com latência variável sob pico (principalmente em “noisy neighbor” interno).

Checklist de decisão (go/no-go) para servidores para empresas

Use esta matriz antes de aprovar a virada para produção. Ela “força” a conversa certa com integrador, time de infraestrutura e aplicações.

Estudo de caso técnico (padrão recorrente em troubleshooting)

Em análises de incidentes, um padrão aparece muito: picos de latência em horários previsíveis.

Quando você cruza:

• janela de backup/snapshot;
• tarefas de antivírus/EDR no host;
• jobs de ETL/relatórios;
• e aumento de acessos de usuários,

o storage vira “o gargalo que não estava no projeto”, porque o sizing foi feito com base em capacidade (TB) e não em capacidade transacional (IOPS/latência).

Em 2026, com mais telemetria e mais dependência de SaaS + integrações, variabilidade virou o novo inimigo. Por isso p95/p99 importam mais do que “pico teórico”.

Onde entra a segurança (sim, isso muda performance)

Criptografia, inspeção, auditoria e EDR podem alterar perfil de I/O e CPU. O erro é tratar segurança como “camada depois”.

Para o Coordenador de TI, a dica é: se o projeto envolve requisitos de conformidade, planeje testes com as mesmas políticas habilitadas que irão para produção.

Leia mais:

Subutilização de servidores: onde o sizing falha na vida real

Vida útil real de servidores: como planejar refresh sem susto

Como a Aviti te ajuda 

Se a sua objeção é o receio de mudar fornecedor, dá para começar com um passo controlado: assessment de performance (telemetria, testes e critérios go/no-go) e um plano de evolução por fase.

Quer validar se você está comprando performance ou gargalo? Agende uma conversa com nossos especialistas e traga seus números (IOPS, latência e perfil de aplicação).