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.
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/secTiming buffered disk reads: 234 MB in 3.00 seconds = 77.98 MB/secsudo hdparm -v /dev/sda também dará informações.
dd lhe dará informações sobre a velocidade de gravação.
Se a unidade não tiver um sistema de arquivos (e so), usar of=/dev/sda.
Caso contrário, monte-o em / tmp e escreva, em seguida, exclua o arquivo de saída de teste.
dd if=/dev/zero of=/tmp/output bs=8k count=10k; rm -f /tmp/output10240+0 records in10240+0 records out83886080 bytes (84 MB) copied, 1.08009 s, 77.7 MB/sMétodo gráfico
- >>Vá para System-Administration-Disk Utility.
- Como alternativa, inicie o utilitário de disco Gnome A partir da linha de comando executando
gnome-disks
- Como alternativa, inicie o utilitário de disco Gnome A partir da linha de comando executando
- Selecione seu disco rígido no painel esquerdo.
- Agora clique no botão" Benchmark – Measure Drive Performance " no painel direito.
- Uma nova janela com gráficos é aberta.Você vai encontrar e dois botões. Um é para "Start Read Only Benchmark" e outro é "Start Read/Write Benchmark". Quando você clica no botão qualquer um, ele inicia o benchmarking do disco rígido.
Como fazer benchmark de E/S de disco
Há algo mais que você quer?
Suominen está certo, devemos usar algum tipo de sincronização; mas há 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/output1024+0records in1024+0 records out402653184 bytes (403 MB) copied, 3.19232 s, 126 MB/sSe você quer precisão, você deve usar fio. Requer a leitura do manual (man fio) mas isso lhe dará resultados precisos. Observe que, para qualquer precisão, você precisa especificar exatamente o que deseja medir. Exemplo:
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_reportingVelocidade de gravação 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_reportingAleatório 4 K ler 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_reportingMisturado Aleatório 4 K ler e escrever QD1 com sincronização (este é o pior número de caso que você deve esperar da 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_reportingAumentar 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 & quot; para mídia rotacional porque a cabeça de leitura não precisa se mover tanto. Se o seu dispositivo estiver quase vazio, usar o arquivo grande o suficiente para quase preencher a unidade obterá o pior comportamento para cada teste. No caso do 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 total de bytes escritos 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 de flash SLC usada como cache de gravação e o desempenho muda quando o cache SLC está cheio (por exemplo, Série Samsung EVO que tem 20-50 GB de cache SLC). 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 uma vez que fica cheio, escrever diretamente na área SMR pode cortar o desempenho para 10% do original. E a única maneira de ver essa degração de desempenho é primeiro escrever 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 estiver repleto de atrasos prolongados que permitem que o dispositivo limpe o cache interno, sequências de teste mais curtas refletirão melhor o desempenho do seu mundo real. Se você precisa fazer muitos IO, você precisa aumentar os dois --io_size e --runtime parametro. Observe que algumas mídias (por exemplo, a maioria barato dispositivos flash) sofrerão de tais testes porque os chips flash são ruins o suficiente para desgastar 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 1000 vezes, porque todas as células de flash terão algum nível de desgaste com a escrita.
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 estiver sendo reescrito 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ê realmente verá na vida real. Se você não conhece a carga de trabalho esperada, usar o tamanho do arquivo de teste que preenche 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, fazer um teste de gravação com arquivo de teste de 25 TB levará algum tempo!
Notar fio irá criar o arquivo temporário necessário na primeira execução. Ele será preenchido com dados pseudo-aleatórios para evitar obter números muito bons de dispositivos que tentam trapacear em benchmarks, comprimindo os dados antes de gravá-los em armazenamento permanente. O arquivo temporário será chamado fio-tempfile.dat em exemplos acima e armazenados no diretório de trabalho atual. Portanto, você deve primeiro mudar para o diretório montado no dispositivo que deseja testar. O fio também suporta o uso de mídia direta como alvo de teste, mas eu definitivamente sugiro ler a página do manual antes de tentar isso porque um erro de digitação pode substituir todo o seu 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, aumentar --numjobs acima. Isso define a simultaneidade para as leituras e gravações. Todos os exemplos acima têm numjobs definir 1 portanto, o teste é sobre leitura e gravação de processo encadeado único (possivelmente com a profundidade da fila ou QD definido com iodepth). SSDs de última geração (por exemplo, Intel Optane 905p) devem obter números altos, mesmo sem aumentar numjobs muito (por exemplo . 4 deve ser suficiente para obter os números de especificação mais altos), mas alguns" empresa & quot; SSDs exigem ir ao intervalo 32-128 para 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 numbjobs para valores elevados geralmente aumenta o resultado desempenho de referência números, mas raramente reflete o desempenho do mundo real de alguma forma.
Eu não recomendaria usar /dev/urandom porque é baseado em software e lento como porco. Melhor pegar um pedaço de dados aleatórios no ramdisk. No teste de disco rígido Aleatório não importa, porque cada byte é escrito como está (também em ssd com dd). Mas se testarmos o pool ZFS depurado com zero puro ou dados aleatórios, há uma enorme diferença de desempenho.
Outro ponto de vista deve ser a inclusão de 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 se 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 in1024+0 records out104857600 bytes (105 MB) copied, 0.270684 s, 387 MB/sreal 0m0.441suser 0m0.004ssys 0m0.124s>portanto, o datarate do disco é apenas 104857600 / 0.441 = 237772335 b / s -- 237mb / s
Isso é mais de 100 MB/s menor do que com cache.
Feliz benchmarking,
Se você quiser monitorar a velocidade de leitura e gravação do disco em tempo real, você pode usar o iotop ferramenta.
Isso é útil para obter informações sobre como um disco é executado para um aplicativo ou carga de trabalho específica. A saída mostrará velocidade de leitura / gravação por processo e velocidade total de leitura / gravação para o servidor, semelhante a top.
Instalar iotop:
sudo apt-get install iotop Execute-o:
sudo iotopEsta ferramenta é útil para entender como um disco funciona para uma carga de trabalho específica versus testes mais gerais e teóricos.
Velocidade de gravação
$ dd if=/dev/zero of=./largefile bs=1M count=10241024+0 records in1024+0 records out1073741824 bytes (1.1 GB) copied, 4.82364 s, 223 MB/sO 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=4k165118+0 records in165118+0 records out676323328 bytes (676 MB) copied, 3.0114 s, 225 MB/sbonnie++ é o melhor utilitário de benchmark que conheço Para linux.
(Atualmente estou preparando um livecd linux trabalhando com bonnie++ para testar nossa máquina baseada no 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. Comparar um usbkey, um disco rígido (rotativo), uma unidade de estado sólido e um sistema de arquivos baseado em ram pode ser muito informativo para o novato.
Não tenho ideia se ele está incluído no Ubuntu, mas você pode compilá-lo facilmente a partir da fonte.
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 jamesUm pouco mais em: EXEMPLO SIMPLES DE BONNIE++ .
Similar question has been asked over on linux - How can I benchmark my HDD? - Unix & Linux Stack Exchange , file io - Testing IO performance in Linux - Stack Overflow and io - I/O Performance Benchmarking Linux - Server Fault .