ディスク速度：ベースラインとバースト

VPSのディスクはNVMeですが、1台のマシンがノードの共有リソースを食いつぶさないよう、速度はティアによって制限されています。この数値を理解しておけば、「CPUは空いているのにデータベースが遅いのはなぜか」という疑問に悩まされずに済みます。

計算方法

書き込みのベースラインは1コアあたり60 MB/sですが、60を下回ることも400 MB/sを上回ることもありません。読み込みは書き込みベースラインの2倍です。ベースラインを超えると、その3倍の値のバーストが30秒間利用できます。

バーストは本来の役割を果たします。アプリケーションの起動、アーカイブの展開、マイグレーションの適用などです。継続的な書き込みストリーム（数ギガバイトのコピー、ビルド、大規模データベースのスキャン）はベースラインで動作します。

測定方法

sudo apt install -y fio
fio --name=w --rw=write --bs=1M --size=2G --numjobs=1 \
    --runtime=60 --time_based --end_fsync=1 --directory=/var/tmp

最初の数秒はバーストを示し、その後速度はベースラインまで低下します。これは正常で想定どおりの挙動であり、故障ではありません。

パッケージをインストールせずに簡単に確認する方法：

dd if=/dev/zero of=/var/tmp/testfile bs=1M count=2048 oflag=direct
rm /var/tmp/testfile

業務時間中に本番マシンでディスクテストを実行しないでください。テストは利用可能な帯域幅を本当にすべて消費し、その数分間はサイトの応答に数秒かかるようになります。また、テストファイルを残さないでください。40 GBのディスク上の2ギガバイトは無視できない割合です。詳しくはディスク容量をご覧ください。

ディスクがボトルネックであると判断する方法

sudo apt install -y sysstat
iostat -x 2 5
vmstat 2 5

2つの指標に注目してください。%utilが100に近く、awaitが数十ミリ秒であれば、ディスクのキューを示しています。vmstatでも兆候は同じです。b列（待機中のプロセス）が増加し、CPU使用率が低い状態です。

もう1つの症状：CPUがほぼアイドル状態なのにload averageが高い。Linuxのload averageはディスクを待っているプロセスもカウントします。

実際に書き込んでいるのは誰か：

sudo iotop -o -b -n 3

ボトルネックに達した場合の対処

• 時間をずらす。 コピー、レジストリのビルド、レポートなどは夜間に、しかも同時に実行しないようにします。詳しくはスケジュールジョブをご覧ください。
• バックグラウンドタスクを制限する。 緊急でないものにはrsync --bwlimit、nice -n 19 ionice -c3 <command>を使用します。
• 書き込みを減らす。 ログサイズを制限し、アプリケーションの過剰な詳細出力を無効にし、再起動後も保持されるならキャッシュをメモリ（tmpfs）に移します。
• データベースをチューニングする。 PostgreSQLやMySQLでは、書き込みの大部分はトランザクションログです。バッファ用のメモリを増やせば、ディスクアクセスが減ります。
• ティアを上げる。 ベースラインはコア数とともに増加します。VDS-1からVDS-2では2倍になります。計画的なアップグレードは上位方向のみ可能で、支払い済み期間の残り日数分を追加でお支払いいただきます。

よくある間違い

• oflag=directなしでddを使って速度を測定する。 データがページキャッシュに収まり、数値が実際より高く出ます。
• バーストを継続的な速度とみなす。 最初の30秒は速く、その後はベースラインです。これは仕様です。
• アクティブなディスクにスワップを置いてスワップする。 メモリが不足すると、スワップがディスクをボトルネックに変えます。コンテナを制限する方がよいでしょう。詳しくはリソース制限をご覧ください。