Uma cópia em Ficheiros do ZimaOS que indique aproximadamente 600–650 MB/s não prova que o próprio dispositivo NVMe esteja limitado à velocidade SATA. O guia da comunidade de origem separa corretamente o débito bruto do armazenamento do débito do fluxo de trabalho de cópia de ficheiros. Um gestor de ficheiros baseado num navegador pode acrescentar metadados, acompanhamento do progresso, lógica de segurança, cópias no espaço do utilizador, sobrecarga do sistema de ficheiros e operações por ficheiro que um benchmark direto não mede.
A abordagem mais útil é comparativa: teste o mesmo armazenamento com uma carga grande de E/S direta sequencial e, em seguida, copie o mesmo ficheiro grande através da CLI e de Ficheiros. Se os testes brutos/diretos atingirem vários GB/s enquanto a cópia na interface gráfica se mantiver perto dos 600 MB/s, o estrangulamento estará provavelmente acima do dispositivo NVMe.
Um único valor de cópia de ficheiros não é um benchmark de NVMe
A velocidade da cópia interna depende de:
- origem e destino serem o mesmo dispositivo ou dispositivos diferentes;
- tipo de sistema de ficheiros;
- comportamento de cópia na escrita;
- tamanho e número de ficheiros;
- sobrecarga do CPU;
- cache de páginas;
- a implementação da cópia.
Um resultado de 600 MB/s pode ser excelente para um fluxo de trabalho e fraco para outro.
Comece com um ficheiro de teste sequencial grande
Ficheiros grandes reduzem o ruído dos metadados e facilitam a interpretação do débito sustentado. A fonte utilizou um ficheiro de 10 GB para que a carga fosse executada durante tempo suficiente para ser observada.
Antes de criar um ficheiro de teste grande, verifique se o armazenamento de destino tem bastante espaço livre. Um benchmark que encha o disco do sistema ou de dados pode provocar uma falha diferente.
A fonte utilizou dd com escritas diretas
O guia da comunidade propôs:
dd if=/dev/zero of=/DATA/testfile bs=1G count=10 oflag=direct status=progressoflag=direct reduz os efeitos da cache de páginas no percurso de escrita. Isto é útil para uma verificação aproximada da escrita sequencial.
Não assuma que todas as compilações, dispositivos ou sistemas de ficheiros aceitam o mesmo tamanho de bloco ou se comportam de forma idêntica relativamente à E/S direta.
Tenha mais cuidado ao interpretar o teste de leitura dd da fonte
A fonte leu depois o ficheiro para /dev/null. Sem uma opção de leitura com E/S direta ou controlo da cache, um ficheiro recente pode ser parcialmente servido a partir da cache de páginas e exagerar a velocidade de leitura aparente.
Para uma comparação de armazenamento fiável, prefira uma ferramenta/configuração que utilize explicitamente E/S direta em ambas as direções ou certifique-se de que compreende os efeitos da cache.
O fio é um benchmark de armazenamento com melhor controlo
O exemplo de escrita sustentada da fonte utilizava:
fio --name=nvme --filename=/DATA/fio.test --size=10G --rw=write --bs=1M --iodepth=32 --numjobs=1 --direct=1 --runtime=30 --group_reportingIsto continua a ser uma orientação da comunidade, mas tem uma estrutura de benchmark mais clara: tamanho de teste explícito, escritas sequenciais, profundidade da fila, E/S direta, duração e resultados agrupados.
Nunca aponte um trabalho fio destrutivo para um dispositivo bruto que contenha dados reais. Utilize um ficheiro de teste descartável num sistema de ficheiros, a menos que compreenda totalmente as consequências.
Comparar a GUI e a CLI com o mesmo conjunto de dados
A recomendação metodológica mais importante da fonte é utilizar o mesmo ficheiro grande para ambos:
- uma cópia através da CLI;
- uma cópia através dos Ficheiros do ZimaOS.
Se o conjunto de dados, a origem, o destino e o sistema de ficheiros forem idênticos, a diferença refletirá mais diretamente o processo de cópia.
Os ficheiros pequenos podem ser drasticamente mais lentos
Milhares de fotografias, ficheiros de projetos, miniaturas ou entradas do AppData exigem operações repetidas de abertura/criação, metadados e somas de verificação. A taxa de transferência agregada pode ficar muito abaixo da de um único filme grande ou ISO, mesmo num NVMe muito rápido.
A cópia na escrita do Btrfs e o comportamento dos metadados podem acrescentar sobrecarga adicional, dependendo da operação exata.
Monitorizar a CPU e a E/S enquanto a cópia lenta está em execução
A fonte recomenda observar a utilização do disco e da CPU ao mesmo tempo. O objetivo é identificar se:
- o disco está saturado;
- um núcleo da CPU é o fator limitante;
- outro processo está a competir pela E/S;
- o processo de cópia está à espera em vez de utilizar plenamente o armazenamento.
Isto é mais informativo do que citar apenas o valor da barra de progresso dos Ficheiros.
A velocidade do NVMe também depende das vias PCIe e do dispositivo
Mesmo um NVMe em bom estado pode funcionar abaixo do valor anunciado se:
- a ranhura é PCIe x1/x2 em vez de x4;
- a plataforma é PCIe Gen 3 em vez de Gen 4;
- o SSD está a sofrer limitação térmica;
- o controlador está a partilhar vias;
- A cache SLC esgota-se durante as escritas sustentadas.
Um teste de desempenho real deve ser comparado com a topologia do hardware, e não com uma expectativa genérica de “NVMe = 7 GB/s”.
Os guias de transferência atuais da IceWhale também distinguem os processos pela interface e os processos de transferência mais rápidos
O guia Thunderbolt da ZimaCube da IceWhale tem mostrado, historicamente, o processo de transferência pela interface do ZimaOS a funcionar mais lentamente do que um processo direto através de Samba/Thunderbolt, reforçando a ideia geral de que a interface de ficheiros não é idêntica ao débito bruto da rede ou do armazenamento.
Utilize a lista de verificação atual para resolução de problemas de transferência do ZimaOS para efetuar as verificações suportadas do lado da rede.
Eliminar os ficheiros de teste quando terminar
Grande dd/fio os ficheiros podem ocupar rapidamente dezenas de gigabytes. Remova os ficheiros de teste conhecidos depois de registar os resultados e verifique o espaço livre posteriormente.
Perguntas frequentes sobre testes de desempenho de NVMe
Uma velocidade de 600 MB/s nos Ficheiros do ZimaOS prova que o NVMe está limitado à velocidade SATA?
Não. Mede esse processo de cópia, não a capacidade bruta do NVMe.
Porque é que uma leitura com dd pode parecer irrealisticamente rápida?
Um ficheiro escrito recentemente pode ser parcialmente servido a partir da cache de páginas, a menos que o teste de leitura evite explicitamente a colocação em cache.
Qual é a melhor comparação para o processo de cópia da GUI?
Utilize a mesma origem/destino e o mesmo conjunto de dados grande tanto na CLI como nos Ficheiros e, em seguida, compare enquanto monitoriza a CPU e a E/S do armazenamento.
