ディスク負荷：iostatとiotop

ディスクは「CPU はアイドルなのにすべてが遅い」という状況で最もよくある原因です。プロセスは I/O 待ちで止まり、ロードアベレージは上がるのに、htop では CPU% がほぼゼロに見えます。これを数値で確認する方法を見ていきましょう。

割り当てられる上限

ノードのディスクは NVMe ですが、速度はティアによって制限されます。書き込みはコアあたり 60 MB/s、ただし下限が 60、上限が 400 MB/s です。読み取りは書き込み速度の 2 倍です。上限を超えると、30 秒間だけ 3 倍のバーストが許可されます。アーカイブの展開やプロジェクトのビルドには十分ですが、テラバイト級のアップロードを継続するには足りません。

計測値がちょうどこれらの数値に達しているなら、上限に達しているだけで、壊れているわけではありません。それを超えるには、ティアを上げるしかありません。

iostat：全体像をつかむ

apt install -y sysstat       # Debian, Ubuntu
dnf install -y sysstat       # AlmaLinux, CentOS Stream

iostat -xz 2

このコマンドは 2 秒ごとにスナップショットを出力します。最初の出力は起動時からの平均なので無視してください。vda または sda の行を見ます。

• r/s、w/s — 1 秒あたりの読み取り・書き込み操作数です。
• rkB/s、wkB/s — メガバイト単位なので 1024 で割ります。上の表と比較してください。
• await — 操作あたりの平均待ち時間（ミリ秒）です。1 桁なら正常で、数十や数百ならキューが溜まっています。
• %util — ディスクの使用率です。90～100 % が続くなら限界に達しています。

vmstat 2 も役立ちます。wa 列（io wait）は、CPU がディスク待ちだけに費やしている時間をパーセントで示します。

iotop：誰が書き込んでいるのかを特定する

apt install -y iotop && iotop -oPa

-o はアクティブなプロセスのみを表示し、-P はスレッドではなくプロセスを表示し、-a は起動時からの累積量を表示します。1 分ほど観察すれば、本当の原因が見えてきます。通常はデータベース、ログ収集ツール、またはバックアップです。

対話的な UI を使わずに一度だけ確認するには、次のようにします。

iotop -boPan 3 | head -20

見つけた原因への対処

• ジャーナルが書き込んでいる。 サイズを制限します。journalctl --vacuum-size=200M を実行し、/etc/systemd/journald.conf に SystemMaxUse=200M を設定します。詳しくは systemd ジャーナル をご覧ください。
• データベースが書き込んでいる。 インデックス不足によりテーブル全体のスキャンが実行されていないか、バッファが小さすぎてすべてディスクに書き出されていないかを確認します。
• 業務時間中のバックアップや rsync。 速度を制限します。rsync --bwlimit=20M を使い、アーカイブ作成には ionice -c3 nice -n19 tar ... を使ってタスクを譲るようにします。
• スワップ。 ページングでディスクが忙しいなら、問題はディスクではなくメモリです。メモリとスワップ をお読みください。

よくある間違い

dd と conv=fdatasync で速度を計測し、1 回の実行結果から結論を出すことです。最初の数秒はバーストで動作するため、実際より高い結果が出ます。正しい計測方法は ディスクとネットワーク速度のベンチマーク にあります。

ディスクが満杯の場合も「すべてが遅い」ように見えます。空き容量がなくなり、サービスが一時ファイルを書き込めずにハングします。まず df -h を確認してください。1 秒で済みます。