Respostas:
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.
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
-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.
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.
Se você precisar de testes mais rigorosos dos seus HDs, use o Bonnie ++ .
hdparm, por referências rápidas. A única desvantagem é que apenas os benchmarks de largura de banda de leitura e o desempenho de muitos tipos de dispositivos de bloco (por exemplo, RAID, iSCSI) podem ser muito assimétricos. Para comparar o desempenho "antes" e "depois" na mesma caixa, ddtambém funciona bem.
hdparm+ ddou apenas bonnie++ou todos os 3. #
(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:
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:
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 .
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:
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 $.
postgresql-contribpacote.
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.
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.)