HDDをどのようにベンチマークできますか？
このようなddを使用してHDDのベンチマークを行うコマンドを確認しました。
$ time sh -c "dd if=/dev/zero of=ddfile bs=8k count=250000 && sync"
これよりも良い方法はありますか？
HDDのベンチマークには通常hdparmを使用します。直接読み取りとキャッシュされた読み取りの両方をベンチマークできます。コマンドを数回実行して、平均値を確立する必要があります。
例
これが直接の読み取りです。
$ 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の使用
私もこの種のテストにddを使用しました。上記のコマンドに加える1つの変更は、このビットをコマンドの最後に追加することです; rm ddfile。
$ time sh -c "dd if=/dev/zero of=ddfile bs=8k count=250000 && sync"; rm ddfile
これにより、コマンドの完了後にddfileが削除されます。 注：ddfileは一時ファイルであり、保持する必要はありません。ddは、 （of=ddfile）、HDDに負荷がかかっているとき。
超えて
HDDのより厳密なテストが必要な場合は、 Bonnie ++ を使用できます。
参考文献
（これは非常に人気のある質問です- https://stackoverflow.com/q/1198691 でそのバリエーションを確認できます https://serverfault.com/q/219739/ 203726 および https://askubuntu.com/q/87035/74041 ）
[ディスクのベンチマーク]には[ddよりも良い]より良い方法はありますか？
はい。ただし、実行に時間がかかり、結果の解釈方法に関する知識が必要になります。実行するテストのタイプに次のような影響があるため、すべてを一度に伝える単一の番号はありません。
- ランダム、シーケンシャル、またはこの2つの混合であるI/Oのパフォーマンスに興味がありますか？
- ディスクの読み取りまたは書き込みを行っていますか？
- 待ち時間、スループット、またはその両方について心配していますか？
- 同じハードディスクのさまざまな部分がどのように機能するかを理解しようとしていますか（通常、回転するディスクの中心に近づくほど高速になります）。
- ディスクの使用時に特定のファイルシステムがどのように機能するかに興味がありますか、またはブロックデバイスに対して直接I/Oを実行することにより、ディスクの生のパフォーマンスにより近い結果が必要ですか？
- 特定サイズのI/Oのパフォーマンスに興味がありますか？
- I/Oを同期または非同期で送信していますか？
- どれだけのI/Oを送信しますか（間違った方法で送信すると、すべてのI/Oがキャッシュされる可能性があるため、ディスクの速度ではなく、RAM ）？
- 書き込んでいるデータのコンテンツはどの程度圧縮可能ですか（たとえば、ゼロのみのデータは非常に圧縮可能であり、一部のファイルシステム/ディスクにはゼロのみのデータ用の特別な高速パスがあり、他のコンテンツでは取得できない数値につながります）？
等々。
以下は、一番上で実行するのが最も簡単で、一番下に近いほど難しい/より徹底的/優れたツールの短いリストです。
- dd（シーケンシャルな読み取りまたは書き込み、スループットのみを表示、ファイルシステムまたはブロックデバイスを使用するように構成可能、ブロックキャッシュをバイパスするように構成可能/ I/Oが実際に完了するまで待機可能）
- hdparm（シーケンシャル読み取りのみ、スループットのみを表示、ファイルシステムを使用しない、ブロックキャッシュをバイパスするように構成可能、キャッシュテストは最初の2Mバイトのみを再読み取り）
- GNOME Disk Utilityのベンチマーク（実行が簡単、ファイルシステムを使用せず、グラフィカルであるが、完全なGNOMEインストールが必要であり、さまざまなタイプのI/Oにレイテンシとスループットの数値を提供しますが、書き込みワークロードは実際にはサンプルサイズごとに読み取り/書き込み/ fsyncを実行しています）。
- fio （ほとんど何でもでき、詳細な結果が得られますが、 設定が必要 とその結果を解釈する方法の理解）。 Linusはそれについて次のように述べています。
Greg-イェンスのFIOコードを取得します。実際の疑似ランダムコンテンツの書き込みなど、ディスクが何らかの「重複除外」（別名「ベンチマークの最適化」）を行っているかどうかを示すことで、正しく機能します。
[ https://github.com/axboe/fio/ ]
それ以外は疑わしいです-ボニーや他の伝統的な道具を忘れてください。
iOPSツール
これらすべてを読むのが面倒な場合は、 IOPSツール をお勧めします。ブロックサイズに応じて、実際の速度がわかります。
それ以外の場合-IOベンチマークを実行するとき、次のことを確認します。
- ブロックサイズ/キャッシュ/ IOPS /直接vsバッファリング/非同期vs同期
- 読み書き
- スレッド
- 待ち時間
CPU使用率
どのブロックサイズを使用しますか：1 GBのディスクに対して1 GBの読み取り/書き込みを行う場合は、1つのI/O操作を実行すればこれは高速です。しかし、アプリケーションがハードディスク全体で512バイトのチャンクを非順次に書き込む必要がある場合（ランダムではありませんがランダムI/Oと呼ばれます）、これは異なって見えます。これで、データベースはデータボリュームに対してランダムI/Oを実行し、ログボリュームに対して順次I/Oを実行します その性質により 。したがって、最初に測定対象を明確にする必要があります。 Linuxをインストールする場合とは異なる大きなビデオファイルをコピーする場合。
このブロックサイズは、実行するI/O操作の数に影響を与えます。あなたがするならOSのI/Oスケジューラーがそれらをマージする8つの順次読み取り（または書き込み、混合ではない）操作。そうでない場合、コントローラのキャッシュがマージを実行します。 512バイトの8つの連続したブロックまたは1つの4096バイトのチャンクを読み取っても、実際には違いはありません。 1つの例外-直接同期を実行できた場合IOで、次の512バイトを要求する前に512バイトを待機します。この場合、ブロックサイズを増やすことは、キャッシュを追加するようなものです。
また、同期IOと非同期IOがあることにも注意する必要があります。syncIOを使用すると、現在のリクエストが戻る前に次のIOリクエストを発行しません。 IOたとえば、10のデータチャンクを要求し、それらが到着するまで待つことができます。Distinctデータベーススレッドは、通常、同期を使用しますIOログと非同期IO。IOPSツールは、512バイトから始まるすべての関連ブロックサイズを測定することで処理します。
読み取りまたは書き込みを行いますか：通常、読み取りは書き込みより高速です。ただし、キャッシングは読み取りと書き込みでまったく異なる方法で機能することに注意してください。
書き込みの場合、データはコントローラーに渡され、キャッシュされる場合は、キャッシュがいっぱいでない限り、データがディスク上にある前に確認応答します。ツール iozone を使用すると、キャッシュエフェクト（CPUキャッシュエフェクトとバッファキャッシュエフェクト）のプラトーの美しいグラフを描くことができます。書き込まれるほど、キャッシュの効率は低下します。
読み取りの場合、最初の読み取り後、読み取りデータはキャッシュに保持されます。最初の読み取りには最も時間がかかり、稼働時間中のキャッシングはますます効果的になります。注目すべきキャッシュは、CPUキャッシュ、OSのファイルシステムキャッシュ、IOコントローラーのキャッシュおよびストレージのキャッシュです。IOPSツール読み取りのみを測定します。これにより、「あちこちで読み取り」が可能になり、読み取りではなく書き込みを行わないようにすることができます。
使用するスレッドの数：1つのスレッドを使用する場合（ ディスクのベンチマークにddを使用 ）、おそらく多くのスレッドを取得します複数のスレッドを使用する場合よりもパフォーマンスが低下します。 IOPSツールはこれを考慮に入れて、いくつかのスレッドで読み取ります。
あなたにとっての待ち時間はどのくらい重要ですか：データベースを見ると、IO待ち時間は非常に重要になります。挿入/更新/削除SQLコマンドは、承認される前にコミット時にデータベースジャーナル（データベース用語では「ログ」）に書き込まれます。これは、データベース全体がこのIO操作の完了を待機している可能性があることを意味します。I show hereiostatツールを使用して平均待機時間（await）を測定する方法.
あなたにとってのCPU使用率はどのくらい重要ですか：CPUは簡単にアプリケーションのパフォーマンスのボトルネックになる可能性があります。この場合、読み書きされるバイトあたりのCPUサイクルの消費量を把握し、その方向に最適化する必要があります。これは、測定結果に応じて、PCIeフラッシュメモリを選択することを意味します。繰り返しますが、iostatツールは、IOオペレーションによるCPU使用率の概算を提供します。
PostgreSQLをインストールしている場合は、優れた pg_test_fsync ベンチマークを使用できます。基本的には、書き込み同期のパフォーマンスをテストします。
Ubuntuでは、次の場所にあります：/usr/lib/postgresql/9.5/bin/pg_test_fsync
それについての素晴らしいことは、このツールがエンタープライズSSDが追加の$に値する理由をあなたに示すことです。
fio- Multithreaded IO generation tool を使用できます。これは、Fedora 25、Debian、OpenCSWなどのいくつかのディストリビューションによってパッケージ化されています。
Fioツールは非常に柔軟性が高く、さまざまなIOシナリオ-同時シナリオを含む）のベンチマークに簡単に使用できます。パッケージには、構成ファイルの例がいくつか含まれています（例：/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
Allルート上のファイル名が見つかり、ランダムにソートされ、最大1分間キャッシュにコピーされます。 cpioからの出力は、コピーされたブロックの数を示します。 3回繰り返して、1分あたりの平均ブロック数を取得します。 （注：検索/並べ替え操作には時間がかかる場合があります-コピーよりもはるかに時間がかかります。検索/並べ替えをキャッシュし、splitを使用してファイルのサンプルを取得することをお勧めします。）
ここで指摘したように here を使用できますgnome-disks（Gnomeを使用している場合）。
テストするドライブをクリックし、[追加のパーティションオプション]（ホイール）をクリックします。次にBenchmark Partition。 MB/s単位の平均読み取り/書き込みとミリ秒単位の平均アクセス時間を取得します。とても快適でした。