Como posso comparar meu HDD?

Eu já vi comandos para avaliar o HD de alguém 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?

Eu costumo usar hdparmpara comparar meus HDDs. Você pode comparar as leituras diretas e as leituras em cache. Você deseja 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 dd

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

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

Isso removerá o ddfileapós a conclusão do comando. OBSERVAÇÃO: ddfile é um arquivo transitório que você não precisa manter, é o arquivo que ddestá gravando em ( of=ddfile) quando está colocando seu HDD em carga.

Indo além

Se você precisar de testes mais rigorosos dos seus HDs, use o Bonnie ++ .

Referências

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

(Essa é uma pergunta muito popular - você pode ver variações dela em https://stackoverflow.com/q/1198691 , https://serverfault.com/q/219739/203726 e https://askubuntu.com/q / 87035/740413 )

Existem métodos melhores [do que dd] para [discos de referência]?

Sim, mas eles 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 só vez, porque os seguintes influenciam o tipo de teste que você deve executar:

• Você está interessado no desempenho de E / S aleatório, seqüencial ou em alguma mistura 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 ambas?
• Você está tentando entender o desempenho de diferentes partes do mesmo disco rígido (geralmente acelera mais rapidamente perto do centro dos discos giratórios)?
• Você está interessado no desempenho de um determinado sistema de arquivos ao usar seu disco ou deseja obter resultados mais próximos do desempenho bruto do disco, executando E / S diretamente em um dispositivo de bloco?
• Você está interessado no desempenho de um tamanho específico de E / S?
• Você está enviando a E / S de forma síncrona ou assíncrona?
• Quanta E / S você está enviando (envie muito pouco da maneira errada e todas as E / S podem ser armazenadas em cache para que você acabe testando a velocidade da sua RAM em vez da velocidade do disco)?
• Qual é a compactação do conteúdo dos dados que você está gravando (por exemplo, dados somente zero são altamente compactáveis ​​e alguns sistemas de arquivos / discos têm até um caminho rápido especial para dados somente zero, levando a números que não podem ser obtidos com outro conteúdo)?

E assim por diante.

Aqui está uma pequena lista de ferramentas mais fáceis de executar no topo e difíceis / mais completas / mais próximas do fundo:

1. dd (leituras ou gravações sequenciais, mostra apenas a taxa de transferência, pode ser configurado para usar um sistema de arquivos ou dispositivo de bloco, pode ser configurado para ignorar o cache do bloco / aguardar que a E / S seja realmente concluída)
2. hdparm (somente leituras sequenciais, apenas mostra a taxa de transferência, nunca usa um sistema de arquivos, pode ser configurado para ignorar o cache do bloco, o teste de cache relê apenas os 2 MBytes iniciais)
3. O benchmark do GNOME Disk Utility (fácil de executar, nunca usa um sistema de arquivos, 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, mas a carga de trabalho de gravação está realmente lendo / gravando / fsync por tamanho de amostra).
4. fio (pode fazer quase qualquer coisa e fornece resultados detalhados, mas requer configuração e entendimento de como interpretar os resultados). Aqui está o que Linus diz sobre isso:

   Greg - obtenha o código FIO de Jens. Ele faz as coisas direito, incluindo a gravação de conteúdo pseudo-aleatório real, que mostra se o disco faz alguma "desduplicação" (também conhecida como "otimizar para benchmarks):

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

   Qualquer outra coisa é suspeita - esqueça o bonnie ou outras ferramentas tradicionais.

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

com a ferramenta IOPS

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

Caso contrário - ao fazer um benchmark de IO, eu observaria o seguinte:

• tamanho do bloco / cache / IOPS / direto vs buffer / assíncrono vs sincronização
• ler escrever
• tópicos
• latência

• Utilização da CPU

• Qual tamanho de bloco 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. Porém, se seu aplicativo precisar gravar blocos de 512 bytes em todo o disco rígido em partes não sequenciais (chamadas de E / S aleatória, embora não seja aleatória), isso será diferente. Agora, os bancos de dados farão E / S aleatória para o volume de dados e E / S seqüencial para o volume de log devido à sua natureza . Então, primeiro você precisa ficar claro o que deseja medir. Se você deseja copiar arquivos de vídeo grandes, é diferente de instalar o Linux.

  Esse tamanho de bloco está afetando a contagem de operações de E / S que você faz. Se você fizer, por exemplo, 8 operações de leitura sequencial (ou gravação, mas não mista), o agendador de E / S do sistema operacional as mesclará. Caso contrário, o cache do controlador fará a mesclagem. Praticamente não há diferença se você ler 8 blocos seqüenciais de 512 bytes ou um pedaço de 4096 bytes. Uma exceção - se você conseguir fazer IO de sincronização direta e aguardar os 512 bytes antes de solicitar os próximos 512 bytes. Nesse caso, aumentar o tamanho do bloco é como adicionar cache.

  Além disso, você deve estar ciente de que há E / S de sincronização e assíncrona: Com o E / S de sincronização, você não emitirá a próxima solicitação de E / S antes que a atual retorne. Com E / S assíncrona, você pode solicitar, por exemplo, 10 blocos de dados e aguardar quando eles chegarem. Os encadeamentos de banco de dados distintos geralmente usam E / S de sincronização para log e E / S assíncrona para dados. A ferramenta IOPS cuida disso medindo todos os tamanhos de bloco relevantes a partir de 512 bytes.

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

  • Para gravações, os dados serão entregues ao controlador e, se ele estiver em cache, reconhecerá 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 platôs de efeitos de cache (efeito de cache da CPU e efeito de cache do buffer). Os caches se tornam menos eficientes quanto mais foram escritos.

  • Para leituras, os dados lidos são mantidos em cache após a primeira leitura. As primeiras leituras demoram mais e o armazenamento em cache se torna cada vez mais eficaz 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 apenas leituras. Isso permite "ler em todo o lugar" e você não deseja que ele escreva em vez de ler.

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

• Qual a importância da latência para você : olhando para os bancos de dados, a latência de IO se torna extremamente importante. Qualquer comando SQL de inserção / atualização / exclusão será gravado no diário do banco de dados ("log" na linguagem do banco de dados) na confirmação 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 (espera) usando a ferramenta iostat .

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

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

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

O melhor de tudo é que esta ferramenta mostra por que os SSDs corporativos valem o valor extra de $.

Você pode usar fio- a ferramenta de geração de E / S multithread . É empacotado por várias distribuições, por exemplo, Fedora 25, Debian e OpenCSW.

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

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

$ 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 [global]seção possui 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 escolhido livremente. Por padrão, trabalhos diferentes são iniciados em paralelo, portanto, o exemplo acima serializa explicitamente a execução do trabalho com a wait_forchave. Além disso, o fio usa um tamanho de bloco de 4 KiB - que também pode ser alterado. O exemplo usa diretamente o dispositivo bruto para trabalhos de leitura e gravação, portanto, certifique-se de usar o dispositivo correto. A ferramenta também suporta o uso de um arquivo / diretório em sistemas de arquivos existentes.

Outras ferramentas

O hdparmutilitário fornece uma referência 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 o fio, apenas deve ser usada para uma primeira verificação de plausibilidade. Por exemplo, para verificar se a unidade USB 3 externa é incorretamente reconhecida como dispositivo USB 2 (você verá taxas de ~ 100 MiB / s vs. ~ 30 MiB / s).

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á leitura / gravação média em MB / se tempo médio de acesso em milissegundos. Achei isso muito confortável.

É um pouco bruto, mas isso funciona muito bem:

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

Você pode fazer algumas coisas interessantes com essa técnica, incluindo armazenar todos os arquivos /libe em cache /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 copiam-os 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. (Observe que a operação de localização / classificação pode demorar muito tempo - muito mais que a cópia. Seria melhor armazenar em cache a localização / classificação e usá-la splitpara obter uma amostra de arquivos.)