回答:
私は通常hdparm、HDDのベンチマークに使用します。直接読み取りとキャッシュ読み取りの両方をベンチマークできます。平均値を確立するには、コマンドを数回実行する必要があります。
これが直接読み取りです。
$ sudo hdparm -t /dev/sda2
/dev/sda2:
Timing buffered disk reads: 302 MB in 3.00 seconds = 100.58 MB/sec
そして、ここにキャッシュされた読み取りがあります。
$ 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.
私もddこの種のテストに使用しました。上記のコマンドに対して行う1つの変更は、コマンドの最後にこのビットを追加することです; rm ddfile。
$ time sh -c "dd if=/dev/zero of=ddfile bs=8k count=250000 && sync"; rm ddfile
これによりddfile、コマンドの完了後にが削除されます。注： ddfileは一時的なファイルであり、保存する必要はありません。HDDに負荷がかかっているときddに（of=ddfile）に書き込むファイルです。
HDDのより厳密なテストが必要な場合は、Bonnie ++を使用できます。
hdparm簡単なベンチマークのためにも、私は好きです。唯一の欠点は、読み取り帯域幅のベンチマークのみであり、多くのタイプのブロックデバイス（RAID、iSCSIなど）のパフォーマンスが非常に非対称になる可能性があることです。同じボックスで「前」と「後」のパフォーマンスを比較する場合ddも、うまく機能します。
hdparm+ ddまたはちょうどbonnie++または全て3
（これは非常に人気の質問です-あなたは上のそれのバリエーションを見ることができますhttps://stackoverflow.com/q/1198691、https://serverfault.com/q/219739/203726とhttps://askubuntu.com/q / 87035/740413）
[ディスクのベンチマーク]に[dd]より優れた方法はありますか？
はい。ただし、実行に時間がかかり、結果の解釈方法に関する知識が必要になります。実行するテストの種類に次の影響があるため、一度にすべてを伝える単一の数字はありません。
等々。
以下は、一番上で実行するのが最も簡単で、一番下で難しい/より徹底的/より良いツールの短いリストです：
Greg-JensのFIOコードを取得します。実際の擬似ランダムコンテンツの書き込みなど、ディスクが何らかの「重複排除」（「ベンチマーク用に最適化」）を行うかどうかを示すなど、適切に処理されます。
[ https://github.com/axboe/fio/ ]
それ以外は疑わしい-ボニーやその他の伝統的なツールを忘れてください。
このすべてを読むのが面倒な場合は、IOPSツールをお勧めします。ブロックサイズに応じて実際の速度がわかります。
それ以外の場合-IOベンチマークを行うとき、次のことを確認します。
CPU使用率
どのブロックサイズを使用しますか：1 GBのディスクから1 GBの読み取り/書き込みを行う場合、1つのI / O操作を行うと、これは迅速になります。ただし、アプリケーションがハードディスク上に512バイトのチャンクを非シーケンシャルピース（ランダムではないがランダムI / Oと呼ばれる）で書き込む必要がある場合、これは見た目が異なります。データベースは、その性質上、データボリュームに対してランダムI / Oを実行し、ログボリュームに対してシーケンシャルI / Oを実行します。そのため、まず、何を測定するかを明確にする必要があります。Linuxをインストールする場合とは異なる大きなビデオファイルをコピーする場合。
このブロックサイズは、実行するI / O操作の数に影響します。たとえば、8つのシーケンシャル読み取り（または、混合ではなく書き込み）操作を実行すると、OSのI / Oスケジューラーがそれらをマージします。そうでない場合、コントローラーのキャッシュがマージを行います。512バイトの8個の連続ブロックまたは4096バイトのチャンクを読み取った場合、実際には違いはありません。1つの例外-直接同期IOを実行し、512バイトを待ってから次の512バイトを要求した場合。この場合、ブロックサイズを増やすことは、キャッシュを追加するようなものです。
また、同期および非同期IOがあることに注意する必要があります。同期IOを使用すると、現在のIOリクエストが返る前に次のIOリクエストを発行しません。非同期IOを使用すると、たとえば10チャンクのデータを要求し、到着するのを待つことができます。通常、個別のデータベーススレッドは、ログに同期IOを使用し、データに非同期IOを使用します。IOPSツールは、512バイトから始まる関連するすべてのブロックサイズを測定することで、これを処理します。
読み取りまたは書き込みを行います：通常、読み取りは書き込みより高速です。ただし、キャッシュは読み取りと書き込みでまったく異なる方法で機能することに注意してください。
書き込みの場合、データはコントローラーに引き渡され、キャッシュされる場合、キャッシュがいっぱいでない限り、データがディスク上にある前に確認します。iozoneツールを使用すると、キャッシュ効果（CPUキャッシュ効果とバッファーキャッシュ効果）のプラトーの美しいグラフを描画できます。キャッシュは、書き込まれるほど効率が低下します。
読み取りの場合、読み取りデータは最初の読み取り後にキャッシュに保持されます。最初の読み取りに最も時間がかかり、キャッシングが稼働中にますます効果的になります。注目すべきキャッシュは、CPUキャッシュ、OSのファイルシステムキャッシュ、IOコントローラーのキャッシュ、ストレージのキャッシュです。IOPSツールは読み取りのみを測定します。これにより、「場所全体を読み取る」ことができ、読み取りの代わりに書き込むことは望ましくありません。
使用するスレッド数：1つのスレッドを使用する場合（ディスクベンチマークにddを使用する場合）、複数のスレッドを使用する場合よりもパフォーマンスが大幅に低下する可能性があります。IOPSツールはこれを考慮して、いくつかのスレッドを読み取ります。
レイテンシーはどれほど重要か：データベースを見ると、IOレイテンシーは非常に重要になります。挿入/更新/削除SQLコマンドは、確認される前にコミット時にデータベースジャーナル（データベース用語では「ログ」）に書き込まれます。これは、完全なデータベースがこのIO操作の完了を待機している可能性があることを意味します。ここでは、iostatツールを使用して平均待機時間（await）を測定する方法を示します。
あなたにとってCPU使用率はどれほど重要か：あなたのCPUは、アプリケーションのパフォーマンスのボトルネックになりやすいでしょう。この場合、読み取り/書き込みのバイトごとにどれだけのCPUサイクルが消費されるかを知り、その方向に最適化する必要があります。これは、測定結果に応じて、PCIeフラッシュメモリの有無を決定することを意味します。この場合も、iostatツールを使用すると、IO操作によるCPU使用率のおおよその見積もりを得ることができます。
PostgreSQLをインストールしている場合、優れたpg_test_fsyncベンチマークを使用できます。基本的に、書き込み同期のパフォーマンスをテストします。
Ubuntuでは、次の場所にあります。 /usr/lib/postgresql/9.5/bin/pg_test_fsync
それの素晴らしいところは、このツールがエンタープライズSSDが余分な$に値する理由を示すことです。
postgresql-contribパッケージで入手できます。
あなたは使用することができますfio- マルチスレッドIO生成ツールを。Fedora 25、Debian、OpenCSWなどのいくつかのディストリビューションでパッケージ化されています。
fioツールは非常に柔軟性が高く、同時実行を含むさまざまなIOシナリオのベンチマークに簡単に使用できます。このパッケージには、いくつかのサンプル設定ファイルが付属しています（egを参照/usr/share/doc/fio/examples）。物事を適切に測定します。つまり、一部の数値の標準偏差と定量統計も印刷します。他の人気のあるベンチマークツールが気にしないもの。
単純な例（一連の単純なシナリオ：順次/ランダム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
呼び出し：
# 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
[..]
[global]セクションにはグローバルなデフォルトがあり、他のセクションでオーバーライドできることに注意してください。各セクションはジョブを説明し、セクション名はジョブ名であり、自由に選択できます。デフォルトでは、異なるジョブが並行して開始されるため、上記の例では、wait_forキーを使用してジョブの実行を明示的にシリアル化し
ます。また、fioは4 KiBのブロックサイズを使用します-これも変更できます。この例では、読み取りジョブと書き込みジョブにrawデバイスを直接使用するため、適切なデバイスを使用するようにしてください。このツールは、既存のファイルシステムでのファイル/ディレクトリの使用もサポートしています。
このhdparmユーティリティは、次のような非常に単純な読み取りベンチマークを提供します。
# hdparm -t -T /dev/sdz
これは、fioのような最先端のベンチマークツールに代わるものではなく、最初の妥当性チェックにのみ使用する必要があります。たとえば、外部USB 3ドライブがUSB 2デバイスとして誤って認識されているかどうかを確認するには（その場合、〜100 MiB / sの対比〜30 MiB / sレートが表示されます）。
それは少し粗雑ですが、これはピンチで動作します：
find <path> -type f -print0 | cpio -0o >/dev/null
この手法を使用する/libと、すべての/usr/binファイルとファイルのキャッシュなど、いくつかの興味深いことができます。ベンチマークの一環としてこれを使用することもできます。
find / -xdev -type f -print0 |
sort -R --from0-file=- |
timeout "5m" cpio -0o >/dev/null
ルート上のすべてのファイル名が検出され、ランダムにソートされ、最大1分間キャッシュにコピーされます。cpioからの出力は、コピーされたブロック数を示します。1分あたりの平均ブロック数を取得するには、3回繰り返します。（注：検索/並べ替え操作には時間がかかる場合があります-コピーよりもはるかに長くなります。検索/並べ替えをキャッシュしてsplit、ファイルのサンプルを取得するために使用することをお勧めします。）