ハードドライブのパフォーマンスを確認する方法（端末またはGUIを使用）。書き込み速度。読み取り速度。キャッシュサイズと速度。ランダムな速度。
回答:
hdparm 始めるには良い場所です。
sudo hdparm -Tt /dev/sda
/dev/sda:
Timing cached reads: 12540 MB in 2.00 seconds = 6277.67 MB/sec
Timing buffered disk reads: 234 MB in 3.00 seconds = 77.98 MB/sec
sudo hdparm -v /dev/sda 情報も提供します。
dd 書き込み速度に関する情報を提供します。
ドライブにファイルシステムがない場合（そしてその場合のみ）、を使用しますof=/dev/sda。
そうでない場合は、/ tmpにマウントし、テスト出力ファイルを書き込んでから削除します。
dd if=/dev/zero of=/tmp/output bs=8k count=10k; rm -f /tmp/output
10240+0 records in
10240+0 records out
83886080 bytes (84 MB) copied, 1.08009 s, 77.7 MB/s
gnome-disks
もっと欲しいものはありますか？
/dev/urandom同様にテストをお勧めします。/dev/zerodd
/tmpファイルシステムは、多くの場合、これらの日RAMディスクを使用しています。したがって、書き込み/tmpは、ディスクサブシステムではなく、メモリをテストしているように見えます。
Suominenは正しいです。何らかの同期を使用する必要があります。しかし、もっと簡単な方法があります、conv = fdatasyncは仕事をします：
dd if=/dev/zero of=/tmp/output conv=fdatasync bs=384k count=1k; rm -f /tmp/output
1024+0records in
1024+0 records out
402653184 bytes (403 MB) copied, 3.19232 s, 126 MB/s
これは/dev/urandomソフトウェアベースであり、ブタのように遅いため、使用はお勧めしません。RAMディスク上のランダムデータのチャンクを取得することをお勧めします。ハードディスクでは、すべてのバイトがそのまま書き込まれるため、ランダムテストは問題になりません（ssdとddでも）。しかし、純粋にゼロまたはランダムなデータで重複排除されたzfsプールをテストすると、パフォーマンスに大きな違いがあります。
もう1つの観点は、同期時間を含める必要があります。すべての最新のファイルシステムは、ファイル操作でキャッシュを使用します。
メモリではなくディスク速度を実際に測定するには、ファイルシステムを同期してキャッシュ効果を取り除く必要があります。それは簡単にできます：
time sh -c "dd if=/dev/zero of=testfile bs=100k count=1k && sync"
そのメソッドを使用すると、出力が得られます。
sync ; time sh -c "dd if=/dev/zero of=testfile bs=100k count=1k && sync" ; rm testfile
1024+0 records in
1024+0 records out
104857600 bytes (105 MB) copied, 0.270684 s, 387 MB/s
real 0m0.441s
user 0m0.004s
sys 0m0.124s
そのため、ディスクのデータレートはわずか104857600 / 0.441 = 237772335 B / s-> 237MB / s
これは、キャッシュを使用する場合よりも100MB / s以上低くなります。
幸せなベンチマーク、
精度が必要な場合は、を使用する必要がありますfio。マニュアル（man fio）を読む必要がありますが、正確な結果が得られます。正確さを保つには、測定対象を正確に指定する必要があることに注意してください。いくつかの例：
大きなブロックでの順次読み取り速度（これは、ドライブの仕様で見られる数値に近いはずです）：
fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=read --size=500m --io_size=10g --blocksize=1024k --ioengine=libaio --fsync=10000 --iodepth=32 --direct=1 --numjobs=1 --runtime=60 --group_reporting
大きなブロックを使用した連続書き込み速度（これは、ドライブの仕様で見られる数値に近いはずです）：
fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=write --size=500m --io_size=10g --blocksize=1024k --ioengine=libaio --fsync=10000 --iodepth=32 --direct=1 --numjobs=1 --runtime=60 --group_reporting
ランダム4K読み取りQD1（これは、確実によく知らない限り、実際のパフォーマンスにとって本当に重要な数値です）：
fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randread --size=500m --io_size=10g --blocksize=4k --ioengine=libaio --fsync=1 --iodepth=1 --direct=1 --numjobs=1 --runtime=60 --group_reporting
混合ランダム4K読み取りおよび同期付きQD1の書き込み（これは、ドライブから予想される最悪のケースの数値であり、通常はスペックシートに記載されている数値の1％未満です）：
fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randrw --size=500m --io_size=10g --blocksize=4k --ioengine=libaio --fsync=1 --iodepth=1 --direct=1 --numjobs=1 --runtime=60 --group_reporting
増加--sizeファイルのサイズを大きくするために、引数を。大きなファイルを使用すると、ドライブテクノロジーとファームウェアによっては、取得する数値が減少する場合があります。読み取りヘッドはそれほど移動する必要がないため、小さなファイルは回転メディアに対して「非常に良い」結果をもたらします。デバイスが空に近い場合、ドライブをほぼいっぱいにするのに十分な大きさのファイルを使用すると、各テストで最悪の場合の動作になります。SSDの場合、ファイルサイズはそれほど重要ではありません。
ただし、一部のストレージメディアでは、ファイルサイズが短時間に書き込まれた合計バイト数ほど重要ではないことに注意してください。たとえば、一部のSSDには事前消去されたブロックのパフォーマンスが大幅に高速化される場合や、書き込みキャッシュとして使用される小さなSLCフラッシュ領域があり、SLCキャッシュがいっぱいになるとパフォーマンスが変化する場合があります。別の例として、Seagate SMR HDDには約20 GBのPMRキャッシュ領域があり、かなり高いパフォーマンスを発揮しますが、一度フルになると、SMR領域に直接書き込むとパフォーマンスが元の10％に低下する場合があります。そして、このパフォーマンスの低下を確認する唯一の方法は、最初に20+ GBをできるだけ速く書き込むことです。もちろん、これはすべてワークロードに依存します。書き込みアクセスがバースト的で、デバイスが内部キャッシュを消去できる長い遅延がある場合、テストシーケンスを短くすると、実際のパフォーマンスが向上します。大量のIOを行う必要がある場合は、両方を増やす必要があります--io_sizeおよび--runtimeパラメーター。一部のメディア（たとえば、ほとんどのフラッシュデバイス）は、このようなテストによって余分な摩耗を受けることに注意してください。私の意見では、この種のテストを処理するのに十分でないデバイスがあれば、どんな場合でも価値のあるデータを保持するために使用すべきではありません。
さらに、一部の高品質SSDデバイスには、よりインテリジェントなウェアレベリングアルゴリズムが搭載されている場合があり、内部SLCキャッシュは、同じアドレス空間（テストファイル合計SLCキャッシュより小さい）。そのようなデバイスでは、ファイルサイズが再び重要になります。実際のワークロードが必要な場合は、実際に実際に表示されるファイルサイズでテストするのが最善です。それ以外の場合は、数値が適切に表示される場合があります。
fio最初の実行時に必要な一時ファイルが作成されることに注意してください。データを圧縮して永続ストレージに書き込むことで不正なデバイスから適切な数を取得することを避けるために、ランダムなデータで満たされます。一時ファイルはfio-tempfile.dat上記の例で呼び出され、現在の作業ディレクトリに保存されます。そのため、最初にテストするデバイスにマウントされているディレクトリに変更する必要があります。
優れたSSDがあり、さらに高い数値を表示する場合は、--numjobs上記の値を増やします。これにより、読み取りと書き込みの同時実行性が定義されます。上記の例はすべてnumjobs設定されている1ため、テストはシングルスレッドプロセスの読み取りと書き込みに関するものです（キューがで設定されている可能性がありますiodepth）。ハイエンドのSSD（例えばインテルOptaneは）さえ増大させることなく、高い数字を取得する必要がありますnumjobs（たとえば、多くのことを4最高スペックの番号を取得するのに十分でなければなりません）が、いくつかの「エンタープライズ」のSSDは、に行く必要が32- 128それらの内部レイテンシのため、仕様の番号を取得しますデバイスは高くなりますが、全体的なスループットは異常です。
max_sectors_kb。上記のコマンド例を変更して、1 MBのブロックサイズを使用するようにしました。これは、実際のハードウェアで機能するようだからです。そして、私もfsync読んで問題ではないことをテストしました。
iodepthし1ます。一部のSSDデバイスが32を超える深さの恩恵を受けることは事実です。しかし、読み取りアクセスを必要とし、32を超えるiodepthを維持できる現実のワークロードを指摘できますか？TL; DR：レイテンシーの高いデバイスで非常に高い読み取りベンチマーク数を再現したい場合はiodepth=256 --numjobs=4、実際にそのような数が表示されることを期待しないでください。
bonnie ++は、Linuxで知っている究極のベンチマークユーティリティです。
（現在、Windowsベースのマシンでテストするために、bonnie ++を使用したLinux LiveCDを準備しています！）
キャッシュ、同期、ランダムデータ、ディスク上のランダムな場所、小さなサイズの更新、大きな更新、読み取り、書き込みなどを処理します。USBキー、ハードディスク（回転式）、ソリッドステートドライブ、およびRAMベースの比較ファイルシステムは初心者にとって非常に有益です。
Ubuntuに含まれているかどうかはわかりませんが、ソースから簡単にコンパイルできます。
書き込み速度
$ dd if=/dev/zero of=./largefile bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 4.82364 s, 223 MB/s
ブロックサイズは実際には非常に大きいです。64kや4kなどの小さいサイズで試すことができます。
読み取り速度
次のコマンドを実行して、メモリキャッシュをクリアします
$ sudo sh -c "sync && echo 3 > /proc/sys/vm/drop_caches"
書き込みテストで作成されたファイルを読み取ります。
$ dd if=./largefile of=/dev/null bs=4k
165118+0 records in
165118+0 records out
676323328 bytes (676 MB) copied, 3.0114 s, 225 MB/s
bonnie ++の使用方法に関するヒント
bonnie++ -d [TEST_LOCATION] -s [TEST_SIZE] -n 0 -m [TEST_NAME] -f -b -u [TEST_USER]
bonnie++ -d /tmp -s 4G -n 0 -m TEST -f -b -u james
もう少し：SIMPLE BONNIE ++ Example。