Um teste de armazenamento útil alinha o tamanho da operação, o padrão de acesso, a concorrência e os requisitos de durabilidade à aplicação. Registre as condições do teste e a distribuição de latência, depois confirme o resultado com medições da aplicação.
Comece com uma pergunta sobre armazenamento, não com uma pontuação
Decida o que você precisa saber antes de executar um benchmark. Você pode estar investigando commits lentos de banco de dados, taxa de transferência de distribuição de arquivos ou um processo de build que cria muitos arquivos pequenos. Essas cargas de trabalho não pedem a mesma coisa ao disco. Uma grande cópia sequencial pode parecer impressionante enquanto diz pouco sobre o atraso experimentado por um serviço que faz pequenas leituras aleatórias.
A NVMe foi projetada para mídia não volátil e E/S paralela eficiente, mas o nome do seu protocolo não descreve todas as partes de um caminho de armazenamento hospedado. Virtualização, o sistema de arquivos, a contenção de recursos e a aplicação ainda importam. Escreva uma hipótese de teste, como se a latência de armazenamento está atrasando uma operação específica, em vez de tentar produzir um número que prove que o servidor inteiro é rápido.
Descreva a carga de trabalho em termos reproduzíveis
Registre o tamanho da operação, o padrão sequencial ou aleatório, a proporção de leitura para escrita, o número de jobs e a profundidade da fila. Inclua o tamanho do conjunto de dados e a duração do teste. A documentação do fio explica esses controles de carga de trabalho e os mecanismos de E/S disponíveis. Uma profundidade pretendida pode não ser alcançada por todos os mecanismos ou configurações, então leia o comportamento relatado, bem como a configuração que você solicitou.
Mantenha uma cópia da descrição do teste ao lado do resultado. Anote o sistema operacional, o sistema de arquivos, as opções de montagem, a atividade do serviço e a capacidade disponível. Se você comparar configurações, altere uma condição relevante por vez. Um teste com um padrão de acesso ou concorrência diferente não pode ser apresentado de forma justa como se apenas o meio de armazenamento tivesse mudado.
| Padrão da aplicação | Dimensão do teste a descrever | Resultado a examinar |
|---|---|---|
| Entrega de arquivos grandes | Leituras sequenciais e clientes concorrentes | Taxa de transferência sustentada e uso da CPU |
| Consulta de registro | Pequenas leituras aleatórias e concorrência representativa | Distribuição de latência e operações concluídas |
| Transação durável | Requisitos de escrita e sincronização | Atraso relacionado ao commit, não apenas a velocidade de escrita em buffer |
| Build ou extração | Operações mistas com arquivos pequenos | Duração do job de ponta a ponta e esperas de E/S |
Controle o cache sem fingir que ele não importa
Um conjunto de dados que cabe na memória pode medir principalmente o comportamento do cache após a primeira passagem. Isso pode ser útil se a aplicação normalmente se beneficia do mesmo cache, mas não deve ser rotulado como desempenho bruto do dispositivo. Escolha deliberadamente se o teste examina um caminho de aplicação aquecido, um conjunto de dados mais frio ou um modo de E/S destinado a reduzir o efeito de buffer do sistema operacional.
O suporte a E/S direta e o alinhamento dependem da plataforma e do mecanismo. Ele também não expressa automaticamente os requisitos de durabilidade da aplicação nem elimina todos os caches da pilha. Declare claramente o modo escolhido e evite comparar um teste com buffer com um teste sem buffer como se representassem o mesmo trabalho. Mantenha os intervalos de aquecimento e de medição separados quando isso ajudar na interpretação.
Leia as caudas de latência junto com a taxa de transferência
A latência média pode ocultar operações lentas que afetam solicitações reais. Examine os percentis relatados e o número de amostras por trás deles. Um percentil alto descreve o limite abaixo do qual uma fração declarada das operações observadas ficou durante aquele teste; não é uma garantia permanente de serviço. Execuções curtas ou não representativas fornecem evidências limitadas sobre períodos de produção movimentados.
Uma profundidade de fila maior pode melhorar a taxa de transferência concluída enquanto aumenta o tempo de espera. Essa troca pode ser adequada para processamento em lote e prejudicar um serviço interativo. Compare resultados em uma concorrência semelhante à da aplicação e monitore a CPU e a pressão de E/S ao mesmo tempo. Pare antes que o teste crie interrupções desnecessárias para outra carga de trabalho que compartilha o ambiente.
Mantenha o teste autorizado e não destrutivo
Use um diretório de teste dedicado ou um volume descartável preparado, com espaço livre suficiente e um plano de limpeza explícito. Nunca aponte um benchmark de escrita para um dispositivo bruto não verificado ou um conjunto de dados de produção. Verifique o alvo e o comportamento de escrita da ferramenta antes de começar e inicie com uma execução limitada. E/S sintética pode consumir capacidade e interferir nos serviços mesmo quando não sobrescreve arquivos úteis.
Para uma avaliação semelhante à de produção, combine uma janela de manutenção e mantenha o monitoramento da aplicação. Use dados fabricados quando possível. Não inferir a confiabilidade do armazenamento a partir de um teste de velocidade: verificações de integridade, backups e restauração são tarefas separadas. Um dispositivo que conclui um benchmark ainda precisa de uma estratégia de recuperação para exclusão, erros de software ou perda da máquina.
Feche o ciclo com evidências da aplicação
Suponha que um serviço de relatórios passe muito tempo esperando por leituras aleatórias. A equipe testa um padrão de leitura representativo e depois repete o relatório real com dados comparáveis. Se o relatório melhorar enquanto seu outro trabalho permanece estável, o resultado apoia a hipótese de armazenamento. Se não, investigue o design da consulta, a memória ou outra dependência em vez de repetir testes sintéticos mais amplos.
A Pulse NVMe e configurações dedicadas selecionadas listam armazenamento NVMe no catálogo SwissOctet. Seus rótulos são especificações, não benchmarks publicados de aplicações. Use um método controlado para avaliar o ambiente entregue e preserve as condições com os resultados. A decisão se fortalece quando a medição de armazenamento e o resultado visível ao usuário respondem à mesma pergunta.
Sua lista prática.
- Defina primeiro a pergunta da aplicação.
- Registre padrão, tamanho de bloco, concorrência e duração.
- Declare as suposições de cache e modo de E/S.
- Inspecione os percentis de latência, bem como a taxa de transferência.
- Use um alvo descartável verificado e uma carga inicial limitada.
- Confirme o resultado com um teste da aplicação.
Os detalhes que importam.
Uma cópia sequencial é suficiente para comparar o armazenamento de banco de dados?+
Normalmente não. O acesso ao banco de dados pode envolver pequenas leituras aleatórias, escritas e sincronização. Modele o padrão relevante e verifique a aplicação real.
A E/S direta prova escritas duráveis?+
Não. Buffer e durabilidade são questões separadas. Alinhe o comportamento de sincronização exigido pela aplicação.
Posso publicar um teste como velocidade garantida de um plano?+
Não. Publique suas condições e escopo. Um resultado medido em uma execução não é uma garantia de nível de serviço ou de desempenho futuro.
Vá à fonte.
Estas referências apoiam os conceitos técnicos deste guia. Siga a documentação atual antes de alterar um sistema em produção.
- fio: documentação do testador de E/S flexível fio.readthedocs.io
- NVM Express: visão geral da especificação e perguntas frequentes nvmexpress.org
- Kernel Linux: Pressure Stall Information docs.kernel.org
Orientação editorial da SwissOctet. Os exemplos são ilustrativos. Especificações de serviço, opções disponíveis e condições contratuais devem ser verificadas separadamente.