なぜlscpuやhdparmだけではディスク評価に不十分なのか?
ddコマンドで書き込み速度が500MB/sと表示されているのに、なぜデータベースの動作が亀のように遅いのか疑問に思ったことはありませんか?駆け出しの頃、私はよくddやhdparmを使ってクイックテストを行っていました。数百MB/sという数字を見て、サーバーが最適化されていると自信を持っていました。しかし、現実はもっと過酷でした。
MySQLやPostgreSQLをデプロイすると、帯域幅に余裕があるにもかかわらず、システムがカクつき始めます。問題はここにあります:ddはシーケンシャル書き込み(sequential write)の速度しか測定しません. 一方で、実際のアプリケーションが必要とするのは、IOPS(1秒あたりの読み書き操作数)と極めて低いレイテンシ(Latency)なのです。
そこで登場するのがfio (Flexible I/O Tester)です。これは複雑な読み書きシナリオを正確にシミュレートするための標準ツールです。かつて私はfioを使って、あるクラウドVPSプロバイダーがリソースを「オーバーセル」していることを証明したことがあります。結果、実際のIOPSは公式サイトの公約の3分の1しかありませんでした。それ以来、新しいサーバーを受け取ったときに最初に叩くコマンドは常にfioです。
各Linuxディストリビューションへのfioのインストール
ほとんどの主要なディストリビューションでは、リポジトリにfioが用意されています。インストールは数秒で完了します。
UbuntuまたはDebianの場合:
sudo apt update && sudo apt install fio -y
CentOS、RHEL、またはAlmaLinuxの場合:
sudo yum install epel-release -y
sudo yum install fio -y
fio --versionを入力して確認します。バージョン3.x以上が表示されれば準備完了です。
ベンチマーク時の主要パラメータを解読する
長いコマンドに惑わされないでください。以下の「黄金のパラメータ」に集中しましょう:
- –direct=1: OSのキャッシュを強制的にバイパスします。RAMの速度ではなく、ハードウェアの真のパフォーマンスを測定できます。
- –rw: テストモード。IOPS의 測定には
randread/randwriteを、スループット(throughput)の測定にはread/writeを使用します。 - –bs (block size): データブロックのサイズ。IOPS(データベース標準)には4k、スループット(大容量ファイルコピー標準)には1Mを使用します。
- –ioengine=libaio: I/O処理方式。Linuxにおいて最も効率的な選択肢です。
- –iodepth: 同時に送信するリクエスト数。NVMe SSDの場合、ディスクをフル稼働させるために32や64に設定することが多いです。
3つの実践的なベンチマークシナリオ
以下は、ディスクの性能を限界まで引き出すために私がよく使う3つのコマンドです。
1. ランダム読み込み(Random Read)IOPSの測定
この指標は、Webサーバーやデータベースにとって極めて重要です。
fio --name=randread --ioengine=libaio --direct=1 --bs=4k --iodepth=64 --size=1G --runtime=60 --rw=randread --filename=testfile --group_reporting
現在の多くのデータベースが同程度の小さなブロック単位でデータを保存しているため、bs=4kを使用します。
2. シーケンシャル書き込み(Sequential Write)スループットの測定
動画配信サーバー、バックアップ、またはログファイルの連続書き込みを行う場合に適しています。
fio --name=seqwrite --ioengine=libaio --direct=1 --bs=1M --iodepth=16 --size=2G --runtime=60 --rw=write --filename=testfile --group_reporting
ここでは、データを大きな「パイプ」に通して帯域幅を最大限に最適化するため、bsを1Mに上げています。
3. 混合パフォーマンス(Mixed R/W)の測定
読み込み70%、書き込み30%という実際の運用環境をシミュレートします。
fio --name=mixed_rw --ioengine=libaio --direct=1 --bs=4k --iodepth=32 --size=1G --runtime=60 --rw=randrw --rwmixread=70 --filename=testfile --group_reporting
結果の読み方:最大値だけを見ないこと
fioが終了した際、高いIOPSを見てすぐに喜ばないでください。以下の3つの指標を確認しましょう:
- IOPS: 1秒あたりの操作数。SATA SSDなら通常80k〜100k、NVMeなら数百万に達することもあります。
- BW (Bandwidth): 転送速度(例:500MiB/s)。
- lat (Latency): これこそがパフォーマンスの「真の鍵」です。
clat(completion latency)に注目してください。高品質なNVMe SSDのレイテンシは通常200us(マイクロ秒)未満です。この数値が数十msに跳ね上がると、システムは非常に重く感じられます。
ヒント:異なる時間帯に少なくとも3回はテストを実行してください。クラウド環境では、リソースを共有する「うるさい隣人(noisy neighbors)」によってパフォーマンスが影響を受けることがよくあります。
ベンチマーク結果を「見かけ倒し」にしないための経験則
何度もベンチマークで失敗を繰り返した後、私はいくつかの重要なルールを導き出しました:
- ディスクが満杯に近い状態でのテストは避ける: 空き容量が10〜20%を下回ると、ガベージコレクションの仕組みによりSSDのパフォーマンスが大幅に低下します。
- テストファイルはRAMより大きくする: サーバーに16GBのRAMがあり、1GBのファイルでテストすると、データがキャッシュに収まってしまうため、あり得ないほど高速な結果が出てしまいます。十分な大きさの
--sizeを選択するか、常に--direct=1を使用してください。 - パスの指定に注意: オペレーティングシステムを完全に消去したくない場合は、絶対に
--filename=/dev/sdaを使用しないでください。必ずディレクトリ内の特定のファイルを指定してください。
これらの共有が、あなたのサーバーの実力を正確に評価する助けになれば幸いです。fioは、ストレージシステムのあらゆる問題を明らかにする優れた顕微鏡のようなものです。

