Questão Como verificar o desempenho do disco rígido


Como verificar o desempenho de um disco rígido (via terminal ou GUI). A velocidade de gravação. A velocidade de leitura. Tamanho e velocidade do cache. Velocidade aleatória.


261
2017-12-12 00:22


origem


Pergunta semelhante foi feita em unix.stackexchange.com/questions/108838/… , stackoverflow.com/questions/1198691/… e serverfault.com/questions/219739/… . - Anon


Respostas:


Método 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/sda dará informações também.

dd lhe dará informações sobre velocidade de gravação.

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

Caso contrário, monte-o em / tmp e escreva e exclua o arquivo de saída do 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. Vá para Sistema -> Administração -> Utilitário de Disco.
    • Como alternativa, inicie o utilitário de disco Gnome na linha de comando executando gnome-disks
  2. Selecione seu disco rígido no painel esquerdo.
  3. Agora clique no botão "Benchmark - Medir desempenho da unidade" no painel direito.
  4. Uma nova janela com gráficos é aberta. Você encontrará dois botões. Uma é para “Benchmark inicial somente leitura” e outra é “Benchmark inicial leitura / gravação”. Quando você clica em qualquer botão, ele inicia o benchmarking do disco rígido.

test

Como fazer um benchmark de E / S de disco

Artigo

Existe algo mais que você quer?


345
2017-12-12 00:34



Eu recomendaria testar /dev/urandom assim como /dev/zero como entradas para dd ao testar um SSD, pois a compressibilidade dos dados pode ter um efeito enorme na velocidade de gravação. - Ian Mackinnon
Não existe tal "System ->" no meu Ubuntu 12.04 Unity. Ou pelo menos eu não encontrei. E eu não vejo essa ferramenta de disco nem dentro das configurações do sistema ... O_o Mas eu finalmente consegui executá-lo: / usr / bin / palimpsest - Fran Marzoa
Note que desde 12.10 é simplesmente chamado de discos e pode ser encontrado através da Unidade. - Paul Lammertsma
No Gnome, isso foi movido para Applications -> System Tools -> Preferences -> Disk Utility. Para aqueles de uso que odeiam a Unidade. - Ken Sharp
o /tmp O sistema de arquivos geralmente está usando um ramdisk atualmente. Então, escrevendo para /tmp parece estar testando sua memória, não seu subsistema de disco. - Zoredache


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

73
2017-08-18 18:31



É uma resposta usando um comando / opção diferente dos outros. Eu vejo que é uma resposta digna de um post próprio. - Alaa Ali
Por que você usou 384k como tamanho de bloco? - Diego F. Durán
@ Diego Não há razão. Foi só um exemplo. Você pode usar qualquer outra coisa. (entre cerca de 4k ... 1M) Claro que blocos maiores proporcionam melhor performance. E, claro, diminuir o número de contagem quando você usa big bs, ou levará um ano para terminar. - Tele
não é confiável por ferramentas de benchmarks como o iozone e os números sysbench são muito menores - MSS


Eu não recomendaria usar /dev/urandom porque é baseado em software e lento como porco. Melhor tomar um monte de dados aleatórios no ramdisk. No teste de disco rígido aleatório não importa, porque cada byte é escrito como é (também no ssd com dd). Mas se testarmos o conjunto zfs desclassificado 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 o armazenamento em cache nas operações de arquivos.

Para realmente medir a velocidade do disco e não a memória, devemos sincronizar o sistema de arquivos para se livrar do efeito de armazenamento em 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 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 o datarate do disco é apenas 104857600 / 0.441 = 237772335 B / s -> 237MB / s

Isso é mais de 100MB / s abaixo do caching.

Benchmarking feliz,


42
2017-12-06 23:18





Se você quiser monitorar o disco ler e escrever velocidade em tempo real, você pode usar o iotop ferramenta.

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

Para instalar o iotop:

sudo apt-get install iotop  

Para executá-lo:

sudo iotop

30
2017-09-17 14:24





O bonnie ++ é o melhor utilitário de benchmark que conheço para o Linux.

(Atualmente estou preparando um linux live-no-trabalho com bonnie ++ 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, grandes atualizações, leituras, gravações, etc. Comparando um usbkey, um disco rígido (rotativo), um drive de estado sólido e um baseado em memória RAM sistema de arquivos pode ser muito informativo para o novato.

Eu não tenho idéia se está incluído no Ubuntu, mas você pode compilá-lo da fonte facilmente.

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


23
2018-02-03 16:13





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

17
2018-05-05 22:12





algumas dicas sobre como usar o 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: BONNIE SIMPLES ++ EXEMPLO.


12
2017-09-28 19:02





Se você quer precisão, você deve usar fio. Requer ler o manual (man fio), mas lhe dará resultados precisos. Note que para qualquer precisão, você precisa especificar exatamente o que você quer medir. Alguns exemplos:

Velocidade de leitura sequencial com grandes blocos (isso deve estar perto do 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 ESCRITA sequencial com grandes blocos (isso deve estar perto do número que você vê nas especificações da sua unidade):

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

Aleatório 4K ler QD1 (este é o número que realmente importa para o desempenho no 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

Misto aleatório 4K ler e escrever QD1 com sincronização (este é o pior número de caso que você deve esperar da sua unidade, geralmente 1-10% do número listado 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

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

Observe que fio criará o arquivo temporário necessário na primeira execução. Ele será preenchido com dados aleatórios para evitar números muito bons de dispositivos que trapaceiam ao compactar os dados antes de gravá-los em um armazenamento permanente. O arquivo temporário será chamado fio-tempfile.dat nos exemplos acima e armazenados no diretório de trabalho atual. Então você deve primeiro mudar para o diretório que está montado no dispositivo que você deseja testar.


9
2018-01-01 18:14



Algumas das configurações de fio são um pouco estranhas e podem não ser ideais. Por exemplo, ter um tamanho de bloco tão grande (2Mbytes) quando você está fazendo E / S direta com um mecanismo de E / S assíncrono pode levar a muita divisão no kernel, criando sobrecarga. Envio periódico fsyncs quando você está apenas fazendo leituras também parece incomum. Eu concordo fio é útil, mas eu recomendo leitores cuidadosamente investigar quais os parâmetros que desejam usar em vez de apenas copiá-los textualmente da versão 20180102 da resposta acima ... - Anon
@Anon: você está certo, o ideal para leitura seqüencial seria combinar /sys/block/sd?/queue/max_sectors_kb porque pode ser menor que o limite real de hardware, o que geralmente é muito mais do que os 2MB no exemplo acima. No entanto, presumo que a pequena sobrecarga causada pela CPU não importa em comparação com a velocidade do dispositivo de E / S real. o fsync é uma não operação para leituras, portanto, isso não afetará os resultados - eu o mantive de modo que seja mais fácil entender as diferenças entre as diferentes linhas de comando. Você está tendo problemas para obter os resultados correspondentes às especificações do fabricante? - Mikko Rantalainen
Não exatamente, eu só tenho (algumas) experiência trabalhando com fio e Linux. Na verdade, se você está adivinhando o melhor tamanho de bloco, seria sábio começar com optimal_io_size se estiver disponível (mas você pode assumir 64Kbytes se for 0 - é o que o kernel faz) .Não exatamente, eu tenho (alguma) experiência trabalhando com fio e Linux. Na verdade, se você está adivinhando o melhor tamanho de bloco, seria melhor começar com optimal_io_size se estiver disponível (mas você pode assumir 64Kbytes se for 0 - é o que o kernel faz). - Anon
Acabei de testar novamente alguns dispositivos. Usando o teste de leitura sequencial acima (tamanho de bloco de 2MB) obtive 280 MB / s da Samsung SSD 850 EVO e 1070 MB / s da Intel 910 SSD. Com tamanho de bloco de 64k e linha de comando idêntica, obtive 268 MB / s de 850 EVO e 1055 MB / s de 910 SSD. Pelo menos para este tipo de dispositivos, usar o tamanho de bloco de 2 MB parece melhorar os resultados em torno de 1-5%, mesmo que isso faça com que o kernel divida os pedidos para o hardware. Eu acho que mesmo com otimizações de kernel a sobrecarga de enviar mais syscalls é pior do que dividir dentro do kernel. - Mikko Rantalainen
Após mais testes, parece que obtenho o maior rendimento sequencial usando a potência de 2 valores que é menor que max_sectors_kb. Eu mudei os comandos de exemplo acima para usar o tamanho de bloco de 1 MB porque isso parece funcionar com o hardware do mundo real. E eu também testei isso fsync não importa para a leitura. - Mikko Rantalainen