Como verificar o desempenho do disco rígido

Método de terminal

hdparmé um bom lugar para começar.

sudo hdparm -Tt /dev/sda

/dev/sda:
Timing cached reads:   12540 MB in  2.00 seconds = 6277.67 MB/sec
Timing buffered disk reads: 234 MB in  3.00 seconds =  77.98 MB/sec

sudo hdparm -v /dev/sdatambém dará informações.

ddfornecerá informações sobre a velocidade de gravação.

Se a unidade não tiver um sistema de arquivos (e somente então ), use of=/dev/sda.

Caso contrário, monte-o em /tmp e grave e exclua o arquivo de saída de teste.

dd if=/dev/zero of=/tmp/output bs=8k count=10k; rm -f /tmp/output

10240+0 records in
10240+0 records out
83886080 bytes (84 MB) copied, 1.08009 s, 77.7 MB/s

Método gráfico

1. Abra o aplicativo "Discos". (Nas versões mais antigas do Ubuntu, vá para Sistema -> Administração -> Utilitário de Disco)
   • Como alternativa, inicie o utilitário de disco Gnome a partir da linha de comando executando gnome-disks
2. Selecione seu disco rígido no painel esquerdo.
3. Agora clique no item de menu “Benchmark Disk...” sob o botão de menu de três pontos, no painel à direita.
4. Uma nova janela com gráficos é aberta. Clique em “Iniciar Benchmark...”. (Nas versões mais antigas, você encontrará dois botões: um é para “Start Read Only Benchmark” e outro é “Start Read/Write Benchmark”. Quando você clica em qualquer botão, ele inicia o benchmarking do disco rígido.)

Como fazer benchmark de E/S de disco

Artigo

Há algo mais que você quer?

Suominen está certo, devemos usar algum tipo de sincronização; mas existe um método mais simples, conv=fdatasync fará o trabalho:

dd if=/dev/zero of=/tmp/output conv=fdatasync bs=384k count=1k; rm -f /tmp/output
1024+0records in
1024+0 records out
402653184 bytes (403 MB) copied, 3.19232 s, 126 MB/s

Se você quer precisão, você deve usar fio. Requer a leitura do manual ( man fio), mas fornecerá resultados precisos. Observe que, para qualquer precisão, você precisa especificar exatamente o que deseja medir. Alguns exemplos:

Velocidade de leitura sequencial com blocos grandes (isso deve estar próximo ao número que você vê nas especificações da sua unidade):

fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=read --size=500m --io_size=10g --blocksize=1024k --ioengine=libaio --fsync=10000 --iodepth=32 --direct=1 --numjobs=1 --runtime=60 --group_reporting

Velocidade de GRAVAÇÃO sequencial com blocos grandes (isso deve estar próximo ao número que você vê nas especificações do seu drive):

fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=write --size=500m --io_size=10g --blocksize=1024k --ioengine=libaio --fsync=10000 --iodepth=32 --direct=1 --numjobs=1 --runtime=60 --group_reporting

Leitura aleatória 4K QD1 (este é o número que realmente importa para o desempenho do mundo real, a menos que você saiba melhor com certeza):

fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randread --size=500m --io_size=10g --blocksize=4k --ioengine=libaio --fsync=1 --iodepth=1 --direct=1 --numjobs=1 --runtime=60 --group_reporting

Leitura e gravação aleatória mista de 4K QD1 com sincronização (este é o número de pior caso que você deve esperar de sua unidade, geralmente menos de 1% dos números listados na folha de especificações):

fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randrw --size=500m --io_size=10g --blocksize=4k --ioengine=libaio --fsync=1 --iodepth=1 --direct=1 --numjobs=1 --runtime=60 --group_reporting

Aumente o --sizeargumento para aumentar o tamanho do arquivo. O uso de arquivos maiores pode reduzir os números obtidos, dependendo da tecnologia da unidade e do firmware. Arquivos pequenos darão resultados "muito bons" para mídia rotacional porque o cabeçote de leitura não precisa se mover muito. Se o seu dispositivo estiver quase vazio, usar um arquivo grande o suficiente para quase encher a unidade fará com que você tenha o pior comportamento para cada teste. No caso de SSD, o tamanho do arquivo não importa muito.

No entanto, observe que, para algumas mídias de armazenamento, o tamanho do arquivo não é tão importante quanto o total de bytes gravados durante um curto período de tempo. Por exemplo, alguns SSDs têm um desempenho significativamente mais rápido com blocos pré-apagados ou podem ter uma pequena área flash SLC que é usada como cache de gravação e o desempenho muda quando o cache SLC está cheio (por exemplo, série Samsung EVO que possui cache SLC de 20 a 50 GB) . Como outro exemplo, os HDDs Seagate SMR têm cerca de 20 GB de área de cache PMR que tem um desempenho bastante alto, mas quando fica cheio, gravar diretamente na área SMR pode reduzir o desempenho para 10% do original. E a única maneira de ver essa degradação de desempenho é primeiro gravar 20+ GB o mais rápido possível e continuar com o teste real imediatamente depois. Claro, tudo isso depende da sua carga de trabalho: se o seu acesso de gravação for intermitente com atrasos longos que permitem que o dispositivo limpe o cache interno, sequências de teste mais curtas refletirão melhor seu desempenho no mundo real.--io_sizee --runtimeparâmetros. Observe que algumas mídias (por exemplo, dispositivos flash mais baratos ) sofrerão com esses testes porque os chips flash são fracos o suficiente para se desgastarem muito rapidamente. Na minha opinião, se algum dispositivo for ruim o suficiente para não lidar com esse tipo de teste, ele não deve ser usado para armazenar dados valiosos em nenhum caso. Dito isto, não repita grandes testes de gravação por milhares de vezes porque todas as células flash terão algum nível de desgaste com a gravação.

Além disso, alguns dispositivos SSD de alta qualidade podem ter algoritmos de nivelamento de desgaste ainda mais inteligentes, onde o cache SLC interno tem inteligência suficiente para substituir os dados no local se estiverem sendo reescritos enquanto os dados ainda estiverem no cache SLC. Para esses dispositivos, se o arquivo de teste for menor que o cache SLC total do dispositivo, o teste completo sempre grava apenas no cache SLC e você obtém números de desempenho mais altos do que o dispositivo pode suportar para gravações maiores. Portanto, para esses dispositivos, o tamanho do arquivo começa a importar novamente. Se você conhece sua carga de trabalho real, é melhor testar com os tamanhos de arquivo que você verá na vida real. Se você não souber a carga de trabalho esperada, usar um tamanho de arquivo de teste que preencha cerca de 50% do dispositivo de armazenamento deve resultar em um bom resultado médio para todas as implementações de armazenamento. Claro, para uma configuração RAID de 50 TB,

Observe que fiocriará o arquivo temporário necessário na primeira execução. Ele será preenchido com dados pseudoaleatórios para evitar obter números muito bons de dispositivos que tentam trapacear nos benchmarks compactando os dados antes de gravá-los no armazenamento permanente. O arquivo temporário será chamado fio-tempfile.datnos exemplos acima e armazenado no diretório de trabalho atual. Portanto, você deve primeiro mudar para o diretório que está montado no dispositivo que deseja testar. O fiotambém suporta o uso de mídia direta como alvo de teste, mas definitivamente sugiro ler a página de manual antes de tentar isso, porque um erro de digitação pode substituir todo o sistema operacional quando se usa acesso direto à mídia de armazenamento (por exemplo, gravar acidentalmente no dispositivo do sistema operacional em vez do dispositivo de teste).

Se você tem um bom SSD e quer ver números ainda maiores, aumente --numjobsacima. Isso define a simultaneidade para as leituras e gravações. Todos os exemplos acima foram numjobsconfigurados para 1que o teste seja sobre leitura e gravação de processo de encadeamento único (possivelmente com a profundidade da fila ou QD definido com iodepth). SSDs de ponta (por exemplo, Intel Optane 905p) devem obter números altos, mesmo sem aumentar numjobsmuito (por exemplo 4, deve ser suficiente para obter os números de especificação mais altos), mas alguns SSDs "Empresa" exigem o alcance 32- 128para obter os números de especificação porque a latência interna desses dispositivos é maior, mas a taxa de transferência geral é insana. Observe que aumentar numbjobspara valores altos geralmente aumenta o desempenho de referência resultantenúmeros, mas raramente reflete o desempenho do mundo real de alguma forma.

Eu não recomendaria usar /dev/urandomporque é baseado em software e lento como um porco. Melhor pegar pedaços de dados aleatórios em ramdisk. No disco rígido, o teste aleatório não importa, porque cada byte é escrito como está (também no ssd com dd). Mas se testarmos o pool zfs desduplicado com zero puro ou dados aleatórios, haverá uma enorme diferença de desempenho.

Outro ponto de vista deve ser a inclusão do tempo de sincronização; todos os sistemas de arquivos modernos usam cache em operações de arquivo.

Para realmente medir a velocidade do disco e não a memória, devemos sincronizar o sistema de arquivos para nos livrar do efeito de cache. Isso pode ser feito facilmente por:

time sh -c "dd if=/dev/zero of=testfile bs=100k count=1k && sync"

com esse método você obtém a saída:

sync ; time sh -c "dd if=/dev/zero of=testfile bs=100k count=1k  && sync" ; rm testfile 
1024+0 records in
1024+0 records out
104857600 bytes (105 MB) copied, 0.270684 s, 387 MB/s

real    0m0.441s
user    0m0.004s
sys 0m0.124s

então a taxa de dados do disco é apenas 104857600 / 0,441 = 237772335 B/s --> 237 MB/s

Isso é mais de 100 MB/s menor do que com o cache.

Bom benchmarking,

Se você deseja monitorar a velocidade de leitura e gravação do disco em tempo real, você pode usar a ferramenta iotop .

Isso é útil para obter informações sobre o desempenho de um disco para um determinado aplicativo ou carga de trabalho. A saída mostrará a velocidade de leitura/gravação por processo e a velocidade total de leitura/gravação do servidor, semelhante a top.

Instalar iotop:

sudo apt-get install iotop  

Executá-lo:

sudo iotop

Essa ferramenta é útil para entender o desempenho de um disco para uma carga de trabalho específica em comparação com testes mais gerais e teóricos.

Velocidade de escrita

$ dd if=/dev/zero of=./largefile bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 4.82364 s, 223 MB/s

O tamanho do bloco é realmente muito grande. Você pode tentar com tamanhos menores, como 64k ou até 4k.

Velocidade de leitura

Execute o seguinte comando para limpar o cache de memória

$ sudo sh -c "sync && echo 3 > /proc/sys/vm/drop_caches"

Agora leia o arquivo que foi criado no teste de gravação:

$ dd if=./largefile of=/dev/null bs=4k
165118+0 records in
165118+0 records out
676323328 bytes (676 MB) copied, 3.0114 s, 225 MB/s

bonnie++ é o utilitário de benchmark final que conheço para linux.

(Atualmente estou preparando um livecd linux no trabalho com bonnie++ nele para testar nossa máquina baseada em Windows com ele!)

Ele cuida do cache, sincronização, dados aleatórios, localização aleatória no disco, atualizações de tamanho pequeno, atualizações grandes, leituras, gravações, etc. sistema de arquivos pode ser muito informativo para o novato.

Não tenho ideia se está incluído no Ubuntu, mas você pode compilá-lo facilmente a partir da fonte.

http://www.coker.com.au/bonnie++/

algumas dicas sobre como usar bonnie++

bonnie++ -d [TEST_LOCATION] -s [TEST_SIZE] -n 0 -m [TEST_NAME] -f -b -u [TEST_USER] 
bonnie++ -d /tmp -s 4G -n 0 -m TEST -f -b -u james

Um pouco mais em: EXEMPLO SIMPLE BONNIE++ .