Um teste de armazenamento útil faz corresponder o tamanho da operação, o padrão de acesso, a concorrência e os requisitos de durabilidade à aplicação. Registe as condições do teste e a distribuição de latência e depois confirme o resultado com medições da aplicação.
Comece com uma questão de armazenamento, não com uma pontuação
Decida o que precisa de saber antes de executar um benchmark. Pode estar a investigar commits lentos de base de dados, débito de distribuição de ficheiros ou um processo de compilação que cria muitos ficheiros pequenos. Essas cargas de trabalho não pedem ao disco a mesma coisa. Uma cópia sequencial grande pode parecer impressionante mas dizer pouco sobre o atraso sentido por um serviço que faz pequenas leituras aleatórias.
O NVMe foi concebido para suportes não voláteis e E/S paralela eficiente, mas o nome do seu protocolo não descreve todas as partes de um caminho de armazenamento alojado. A virtualização, o sistema de ficheiros, a contenção de recursos e a aplicação continuam a importar. Escreva uma hipótese de teste, como se a latência do armazenamento está a atrasar uma operação específica, em vez de tentar produzir um número que prove que todo o servidor é rápido.
Descreva a carga de trabalho em termos reprodutíveis
Registe o tamanho da operação, o padrão sequencial ou aleatório, a proporção de leitura para escrita, o número de tarefas e a profundidade da fila. Inclua o tamanho do conjunto de dados e a duração do teste. A documentação do fio explica estes controlos de carga de trabalho e os motores de E/S disponíveis. Uma profundidade pretendida pode não ser alcançada por todos os motores ou configurações, por isso leia o comportamento reportado, bem como a configuração que solicitou.
Guarde uma cópia da descrição do teste junto ao resultado. Anote o sistema operativo, o sistema de ficheiros, as opções de montagem, a atividade do serviço e a capacidade disponível. Se comparar configurações, altere uma condição relevante de cada 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 suporte de armazenamento tivesse mudado.
| Padrão da aplicação | Dimensão do teste a descrever | Resultado a examinar |
|---|---|---|
| Entrega de ficheiros grandes | Leituras sequenciais e clientes concorrentes | Débito sustentado e utilização de CPU |
| Consulta de registo | 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 com o commit, não apenas a velocidade de escrita em buffer |
| Compilação ou extração | Operações mistas de ficheiros pequenos | Duração da tarefa ponta a ponta e esperas de E/S |
Controle a cache sem fingir que não importa
Um conjunto de dados que cabe em memória pode medir sobretudo o comportamento da cache após a primeira passagem. Isso pode ser útil se a aplicação beneficiar normalmente da mesma cache, mas não deve ser rotulado como desempenho bruto do dispositivo. Escolha deliberadamente se o teste examina um caminho de aplicação quente, um conjunto de dados mais frio ou um modo de E/S destinado a reduzir o efeito de buffering do sistema operativo.
O suporte de E/S direta e o alinhamento dependem da plataforma e do motor. Também não expressa automaticamente os requisitos de durabilidade da aplicação nem elimina todas as caches da pilha. Indique 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 à interpretação.
Leia as caudas de latência juntamente com o débito
A latência média pode ocultar operações lentas que afetam pedidos reais. Examine os percentis reportados e o número de amostras por trás deles. Um percentil elevado descreve o limite abaixo do qual caiu uma fração declarada das operações observadas durante esse teste; não é uma garantia permanente de serviço. Execuções curtas ou não representativas dão evidência limitada sobre períodos de produção ocupados.
Uma profundidade de fila mais elevada pode melhorar o débito concluído ao mesmo tempo que aumenta o tempo de espera. Esse compromisso pode adequar-se ao processamento em lote e prejudicar um serviço interativo. Compare resultados com uma concorrência semelhante à da aplicação e monitorize CPU e a pressão de E/S ao mesmo tempo. Pare antes que o teste crie perturbações desnecessárias a outra carga de trabalho que partilhe 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 comece com uma execução limitada. A E/S sintética pode consumir capacidade e interferir com serviços mesmo quando não sobrescreve ficheiros úteis.
Para uma avaliação semelhante à de produção, acorde uma janela de manutenção e mantenha a monitorização da aplicação. Use dados fabricados quando possível. Não inferir a fiabilidade do armazenamento a partir de um teste de velocidade: as verificações de integridade, as cópias de segurança e o restauro são tarefas separadas. Um dispositivo que conclui um benchmark continua a precisar de uma estratégia de recuperação para eliminação, erros de software ou perda da máquina.
Feche o ciclo com evidência da aplicação
Suponha que um serviço de relatórios passa grande parte do tempo à espera de leituras aleatórias. A equipa testa um padrão de leitura representativo e depois repete o relatório real contra dados comparáveis. Se o relatório melhorar enquanto o seu outro trabalho se mantém estável, o resultado apoia a hipótese do armazenamento. Se não melhorar, investigue o desenho da consulta, a memória ou outra dependência em vez de repetir testes sintéticos mais amplos.
O Pulse NVMe e configurações dedicadas selecionadas listam armazenamento NVMe no catálogo SwissOctet. Os seus rótulos são especificações, não benchmarks de aplicações publicados. Use um método controlado para avaliar o ambiente entregue e preserve as condições com as conclusões. A decisão torna-se mais forte quando a medição do armazenamento e o resultado visível ao utilizador respondem à mesma questão.
A sua lista de verificação prática.
- Defina primeiro a questão da aplicação.
- Registe o padrão, o tamanho do bloco, a concorrência e a duração.
- Declare as suposições de cache e de modo de E/S.
- Inspecione os percentis de latência, bem como o débito.
- Use um alvo descartável verificado e uma carga inicial limitada.
- Confirme a conclusão com um teste da aplicação.
Os detalhes que importam.
Uma cópia sequencial é suficiente para comparar armazenamento de base de dados?+
Normalmente não. O acesso à base 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. O buffering e a durabilidade são questões separadas. Faça corresponder o comportamento de sincronização exigido pela aplicação.
Posso publicar um teste como uma velocidade de plano garantida?+
Não. Publique as suas condições e âmbito. Um resultado medido numa execução não é uma garantia de nível de serviço ou de desempenho futuro.
Vá à fonte.
Estas referências sustentam os conceitos técnicos deste guia. Siga a documentação atual antes de alterar um sistema de produção.
- fio: Documentação do testador de E/S flexível fio.readthedocs.io
- NVM Express: Visão geral da especificação e FAQ nvmexpress.org
- Kernel Linux: Pressure Stall Information docs.kernel.org
Orientação editorial da SwissOctet. Os exemplos são ilustrativos. As especificações de serviço, as opções disponíveis e as condições contratuais devem ser verificadas separadamente.