Como posso avaliar meu HDD?

Question

Eu vi comandos para avaliar o próprio HDD como este usando dd :

$ time sh -c "dd if=/dev/zero of=ddfile bs=8k count=250000 && sync"

Existem métodos melhores para fazer isso do que isso?

    

Answer 1

Eu costumo usar hdparm para comparar meus HDDs. Você pode comparar as leituras diretas e as leituras em cache. Você desejará executar os comandos algumas vezes para estabelecer um valor médio.

Exemplos

Aqui está uma leitura direta.

$ sudo hdparm -t /dev/sda2

/dev/sda2:
 Timing buffered disk reads: 302 MB in  3.00 seconds = 100.58 MB/sec

E aqui está uma leitura em cache.

$ sudo hdparm -T /dev/sda2

/dev/sda2:
 Timing cached reads:   4636 MB in  2.00 seconds = 2318.89 MB/sec

Detalhes

-t     Perform  timings  of  device reads for benchmark and comparison 
       purposes.  For meaningful results, this operation should be repeated
       2-3 times on an otherwise inactive system (no other active processes) 
       with at least a couple of megabytes of free memory.  This displays  
       the  speed of reading through the buffer cache to the disk without 
       any prior caching of data.  This measurement is an indication of how 
       fast the drive can sustain sequential data reads under Linux, without 
       any filesystem overhead.  To ensure accurate  measurements, the 
       buffer cache is flushed during the processing of -t using the 
       BLKFLSBUF ioctl.

-T     Perform timings of cache reads for benchmark and comparison purposes.
       For meaningful results, this operation should be repeated 2-3
       times on an otherwise inactive system (no other active processes) 
       with at least a couple of megabytes of free memory.  This displays
       the speed of reading directly from the Linux buffer cache without 
       disk access.  This measurement is essentially an indication of the
       throughput of the processor, cache, and memory of the system under 
       test.

Usando o dd

Eu também usei dd para esse tipo de teste também. Uma modificação que eu faria no comando acima é adicionar esse bit ao final do comando, ; rm ddfile .

$ time sh -c "dd if=/dev/zero of=ddfile bs=8k count=250000 && sync"; rm ddfile

Isso removerá o ddfile após a conclusão do comando. OBSERVAÇÃO: ddfile é um arquivo temporário que você não precisa manter, é o arquivo em que dd está gravando ( of=ddfile ), quando está colocando o disco rígido sob carga. / p>

Indo além

Se você precisar de testes mais rigorosos dos seus HDDs, você pode usar o Bonnie ++ .

Referências

• Como usar o 'dd' para comparar seu disco ou CPU?
• E / S de disco de referência com DD e Bonnie ++

Answer 2

Essa é uma pergunta muito popular (você pode ver variações dela no link , link e link ).

Are there better methods [than dd] to [benchmark disks]?

Sim, mas levarão mais tempo para serem executados e exigirão conhecimento de como interpretar os resultados. Não há um número único que informe tudo de uma vez, pois o seguinte influencia o tipo de teste que você executará:

• Você está interessado no desempenho de I / O que é aleatório, seqüencial ou algum mix dos dois?
• Você está lendo ou gravando no disco (ou alguma mistura dos dois)?
• Você está preocupado com latência, taxa de transferência ou ambos?
• Você está tentando entender o desempenho de diferentes partes do mesmo disco rígido (geralmente acelera um pouco mais rápido próximo ao centro do disco)?
• Você está interessado em números brutos ou como um determinado sistema de arquivos executará ao usar seu disco?
• Você está interessado em como um determinado tamanho de I / O é executado?
• Você está enviando a E / S de forma síncrona ou assíncrona?
• Quanto de E / S você está enviando (submeta muito pouco do jeito errado e toda a E / S pode ser armazenada em cache para que você acabe testando a velocidade da sua RAM em vez da velocidade do disco)?

E assim por diante.

Supondo que você está interessado em benchmarks brutos e fora do sistema de arquivos, aqui está uma pequena lista de ferramentas com as mais fáceis de executar no topo e difícil / melhor / mais detalhado mais próximo do final:

1. dd (sequencial, mostra apenas o rendimento, mas configurado corretamente, pode ser feito para ignorar o cache do bloco / esperar que a E / S seja realmente concluída)
2. hdparm (sequencial, apenas leituras de testes, apenas mostra taxa de transferência, funciona apenas com dispositivos ATA, não considera a sobrecarga do sistema de arquivos, mas é configurado corretamente para ignorar o cache de blocos)
3. O benchmark do GNOME Disk Utility (fácil de executar, gráfico, mas requer uma instalação completa do GNOME, fornece números de latência e taxa de transferência para diferentes tipos de E / S).
4. fio (pode fazer quase tudo e fornece resultados detalhados, mas requer configuração e uma compreensão de como interpretar esses resultados. Veja o que Linus diz sobre isso:

   Greg - get Jens' FIO code. It does things right, including writing actual pseudo-random contents, which shows if the disk does some "de-duplication" (aka "optimize for benchmarks):

   [ https://github.com/axboe/fio/ ]

   Anything else is suspect - forget about bonnie or other traditional tools.

Fonte: comentário deixado no Google Plus para Greg Kroah- Hartman por Linus Torvalds .

    

Answer 3

com a ferramenta IOPS

Se você não se incomodar em ler tudo isso, recomendo a ferramenta de IOPS . Ele dirá a você a velocidade do mundo real, dependendo do tamanho do bloco.

Caso contrário - ao fazer um benchmark de IO, eu olharia para as seguintes coisas:

• blocksize / cache / IOPS / direta vs buffer / assíncrona vs sincronização
• ler / escrever
• threads
• latência

• Utilização da CPU

• Que blocksize você usará : Se você quiser ler / gravar 1 GB de / para o disco, isso será rápido se você fizer uma operação de E / S. Mas se o seu aplicativo precisar escrever em blocos de 512 bytes em todo o disco rígido em partes não seqüenciais (chamadas de E / S aleatória, embora não seja aleatório), isso terá uma aparência diferente. Agora, os bancos de dados farão E / S aleatórias para o volume de dados e E / S sequencial para o volume de log devido à sua natureza . Então, primeiro você precisa se tornar claro o que você quer medir. Se você deseja copiar arquivos de vídeo grandes, é diferente do que se você deseja instalar o Linux.

  Esse tamanho de bloco está afetando a contagem de operações de E / S que você faz. Se você fizer, e. 8 operações de leitura seqüencial (ou gravação, apenas não misturadas) o agendador de E / S do SO irá mesclá-las. Se isso não acontecer, o cache do controlador fará a mesclagem. Não há praticamente nenhuma diferença se você ler 8 blocos sequenciais de 512 bytes ou um bloco de 4096 bytes. Uma exceção - se você conseguir fazer a sincronização direta de E / S e esperar pelos 512 bytes antes de solicitar os próximos 512 bytes. Nesse caso, aumentar o tamanho do bloco é como adicionar o cache.

  Além disso, você deve estar ciente de que há IO de sincronização e assíncrono: com o IO de sincronização, você não emitirá a próxima solicitação de IO antes que a atual retorne. Com o IO assíncrono, você pode solicitar, e. 10 pedaços de dados e, em seguida, espere conforme eles chegam. Encadeamentos de banco de dados disctinct normalmente usam IO de sincronização para log e async IO para dados. A ferramenta IOPS cuida disso medindo todos os tamanhos de bloco relevantes, começando com 512 bytes.

• Você vai ler ou escrever : Normalmente, a leitura é mais rápida do que a escrita. Mas observe que o armazenamento em cache funciona de maneira bem diferente para leituras e gravações:

  • Para gravações, os dados serão entregues ao controlador e, se estiverem em cache, confirmarão antes que os dados estejam no disco, a menos que o cache esteja cheio. Usando a ferramenta iozone você pode desenhar belos gráficos de patamares de efeitos de cache (efeito de cache da CPU e efeito do cache de buffer). Os caches se tornam menos eficientes quanto mais se escreve.

  • Para leituras, os dados lidos são mantidos em cache após a primeira leitura. As primeiras leituras demoram mais e o cache torna-se cada vez mais efetivo durante o tempo de atividade. Caches notáveis são o cache da CPU, o cache do sistema de arquivos do SO, o cache do controlador IO e o cache do armazenamento. A ferramenta IOPS mede somente leituras. Isso permite "ler em todo o lugar" e você não quer que ele escreva em vez de ler.

• Quantos tópicos você usará : Se você usar um thread ( usando o dd para benchmarks de disco você provavelmente terá um desempenho muito pior do que com vários threads. A ferramenta IOPS leva isso em consideração e lê vários tópicos.

• Quão importante é a latência para você : Olhando para bancos de dados, a latência de IO se torna extremamente importante. Qualquer comando SQL insert / update / delete será gravado no diário do banco de dados ("log" na linguagem do banco de dados) no commit antes de ser reconhecido. Isso significa que o banco de dados completo pode estar aguardando a conclusão dessa operação de E / S. Eu mostro aqui como medir o tempo médio de espera (aguarde) usando a ferramenta iostat .

• Quão importante é a utilização da CPU para você : sua CPU pode facilmente se tornar o gargalo para o desempenho de seu aplicativo. Nesse caso, você deve saber quantos ciclos de CPU são queimados por byte lido / escrito e otimizar nessa direção. Isso pode significar decidir para / contra a memória flash PCIe, dependendo dos resultados da medição. Novamente, a ferramenta iostat pode fornecer uma estimativa aproximada da utilização da CPU por suas operações de E / S.

Answer 4

Se você instalou o PostgreSQL, pode usar o excelente benchmark pg_test_fsync . Basicamente testa seu desempenho de sincronização de gravação.

No Ubuntu você encontra aqui: /usr/lib/postgresql/9.5/bin/pg_test_fsync

A melhor coisa é que essa ferramenta mostrará por que os SSDs corporativos valem a quantia extra de $.

    

Answer 5

Você pode usar a ferramenta de geração fio - the Multithreaded IO . É empacotado por várias distribuições, e. Fedora 25, Debian e OpenCSW.

A ferramenta fio é muito flexível, pode ser facilmente usada para avaliar várias IO cenários - incluindo os concorrentes. O pacote vem com algum exemplo arquivos de configuração (por exemplo, /usr/share/doc/fio/examples ). Ele mede adequadamente as coisas, ou seja, também imprime desvio padrão e estatísticas quantitativas para alguns números. Coisas algumas outras ferramentas populares de benchmarking não se importam.

Um exemplo simples (uma sequência de cenários simples: leitura / escrita X sequencial / aleatória):

$ cat fio.cfg
[global]
size=1g
filename=/dev/sdz

[randwrite]
rw=randwrite

[randread]
wait_for=randwrite
rw=randread
size=256m

[seqread]
wait_for=randread
rw=read

[seqwrite]
wait_for=seqread
rw=write

A chamada:

# fio -o fio-seagate-usb-xyz.log fio.cfg
$ cat fio-seagate-usb-xyz.log
[..]
randwrite: (groupid=0, jobs=1): err= 0: pid=11858: Sun Apr  2 21:23:30 2017
  write: io=1024.0MB, bw=16499KB/s, iops=4124, runt= 63552msec
clat (usec): min=1, max=148280, avg=240.21, stdev=2216.91
 lat (usec): min=1, max=148280, avg=240.49, stdev=2216.91
clat percentiles (usec):
 |  1.00th=[    2],  5.00th=[    2], 10.00th=[    2], 20.00th=[    7],
 | 30.00th=[   10], 40.00th=[   11], 50.00th=[   11], 60.00th=[   12],
 | 70.00th=[   14], 80.00th=[   16], 90.00th=[   19], 95.00th=[   25],
 | 99.00th=[ 9408], 99.50th=[10432], 99.90th=[21888], 99.95th=[38144],
 | 99.99th=[92672]
bw (KB  /s): min= 7143, max=371874, per=45.77%, avg=15104.53, stdev=32105.17
lat (usec) : 2=0.20%, 4=15.36%, 10=6.58%, 20=69.35%, 50=6.07%
lat (usec) : 100=0.49%, 250=0.07%, 500=0.01%, 750=0.01%
lat (msec) : 4=0.01%, 10=1.20%, 20=0.54%, 50=0.08%, 100=0.03%
lat (msec) : 250=0.01%
  cpu          : usr=1.04%, sys=4.79%, ctx=4977, majf=0, minf=11
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
 submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
 complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
 issued    : total=r=0/w=262144/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
 latency   : target=0, window=0, percentile=100.00%, depth=1
randread: (groupid=0, jobs=1): err= 0: pid=11876: Sun Apr  2 21:23:30 2017
  read : io=262144KB, bw=797863B/s, iops=194, runt=336443msec
[..]
bw (KB  /s): min=  312, max= 4513, per=15.19%, avg=591.51, stdev=222.35
[..]

Observe que a seção [global] tem padrões globais que podem ser substituídos por outras seções. Cada seção descreve um trabalho, o nome da seção é o nome do trabalho e pode ser livremente escolhido. Por padrão, trabalhos diferentes são iniciados em paralelo, Assim, o exemplo acima serializa explicitamente a execução do trabalho com o wait_for chave. Além disso, o fio usa um tamanho de bloco de 4 KiB - que pode ser alterado, como bem. O exemplo usa diretamente o dispositivo bruto para trabalhos de leitura e gravação, Certifique-se de usar o dispositivo correto. A ferramenta também suporta o uso de arquivo / diretório em sistemas de arquivos existentes.

Outras ferramentas

O utilitário hdparm fornece um benchmark de leitura muito simples, por exemplo:

# hdparm -t -T /dev/sdz

Não é um substituto para uma ferramenta de benchmarking de última geração, como fio, só deve ser usado para uma primeira verificação de plausibilidade. Por exemplo, para verificar se o drive USB 3 externo é erroneamente reconhecido como dispositivo USB 2 (você veria ~ 100 MiB / s vs. ~ 30 MiB / s taxas então).

    

Answer 6

Como apontado aqui aqui , você pode usar gnome-disks ( se você usa o Gnome).

Clique na unidade que deseja testar e clique em "Opções adicionais de partição" (as rodas). Então Benchmark Partition . Você obterá média de leitura / gravação em MB / s e tempos médios de acesso em milissegundos. Eu achei isso muito confortável.

    

Answer 7

É um pouco grosseiro, mas isso funciona bem:

find <path> -type f -print0 | cpio -0o >/dev/null

Você pode fazer algumas coisas interessantes com essa técnica, incluindo o armazenamento em cache de todos os arquivos /lib e /usr/bin . Você também pode usar isso como parte de um esforço de benchmarking:

find / -xdev -type f -print0 | 
sort -R --from0-file=- | 
timeout "5m" cpio -0o >/dev/null

Todos os nomes de arquivos na raiz são encontrados, classificados aleatoriamente e copiados no cache por até 1 minuto. A saída do cpio informa quantos blocos foram copiados. Repita 3 vezes para obter uma média de blocos por minuto. (Note que a operação find / sort pode levar muito tempo - muito mais que a cópia. Seria melhor armazenar em cache a localização / classificação e usar split para obter uma amostra de arquivos.)