サーバーと仮想マシン

I/O 待機を理解する：低速のストレージがサーバーの速度を低下させる場合

I/O 待機ホスティング CPU が低速のドライブを待機し、メモリサブシステムで要求が滞留している場合に、アプリケーションの速度が低下します。I/O 待機時間を認識し、ボトルネックを明確に特定し、 サーバーストレージ速度 意図的に向上させる。.

中心点

I/O待機 CPU が低速のデータストレージを待機していることを示しています。.
測定値 レイテンシ、IOPS、キューの深さなどが速度を決定します。.
アップグレード SSD/NVMe および RAID 10 により、待ち時間が大幅に短縮されます。.
キャッシング RAM、Redis、または Memcached に保存することで、ストレージの負荷を軽減します。.
モニタリング iostat/iotop を使用すると、ボトルネックを早期に発見できます。.

I/O待機について簡潔かつ明確に説明

iowait 値が上昇すると、CPU は データキャリア 計算する代わりに。この状態は、プロセスが読み取りまたは書き込み操作を開始し、ドライブの応答が十分に速くない場合に発生します。私は、CPU のボトルネックと I/O のボトルネックを区別しています。iowait がない状態で CPU 使用率が高い場合は計算負荷が高いことを示し、iowait 値が高い場合はストレージの速度不足を示しています。キューが長くなり、 レイテンシー リクエストごとに増加し、実効スループットは低下します。同時 I/O リクエストが多いほど、ストレージの速度低下は各アプリケーションに大きな影響を与えます。.

サーバーの典型的な症状

私はまず、I/Oの問題が動作の遅延として現れることに気づきます。 データベース APIの応答時間が長くて遅くなる。ファイルやログへのアクセスでWebプロセスがブロックされ、cronジョブが予定より長く実行され、バッチワークロードが夜間に延期される。モニタリングでは、キューの深さが大きく、I/Oごとの待ち時間が目立って長いことがわかる。CPUは「空き」状態に見えるが、リクエストの処理が遅い。 プレート 追いつけない。まさにここで、レイテンシ、IOPS、およびキューの長さに沿った正確な診断が役立ちます。.

パフォーマンス指標を正しく読み取る

iowait、レイテンシ、IOPS、スループット、および キューの深さ iostat、iotop、vmstat、sar などのツールを使用します。読み取りと書き込みの個別の値に関心があります。書き込みパスは、読み取りアクセスとは異なるボトルネックを示すことが多いからです。私は、平均値だけでなく、レイテンシの 95 パーセンタイルと 99 パーセンタイルも観察しています。ランダムアクセスが多い小さなファイルも、大きなシーケンシャルストリームとは動作が異なります。私は、これらのメトリックを相互に関連付けて、真のボトルネックを可視化しています。.

次の表は、測定値を分類し、迅速に判断を下すのに役立ちます。

指標	基準値	ヒント	次のステップ
iowait (%)	> 10～15 %（数分間）	CPU は明らかに I/O を待機しています。	ストレージを確認し、キャッシュを増やす
r_await / w_await (ms)	> 5 ミリ秒 SSD、> 1 ミリ秒 NVMe	高いレイテンシー手術ごとに	I/Oパスを短縮し、NVMeをテストする
avgqu-sz	> 1 永続的	待ち行列が混雑している	並列処理を抑制し、キャッシュを活用する
IOPS	予想を大きく下回る	デバイスが制限されます	スケジューラ/キャッシュ/RAID を確認する
スループット（MB/s）	大きく変動する	邪魔になるものスパイク目に見える	QoSの設定、バックグラウンドジョブのタイミング設定

原因を正しく分類する

私は、あまりにも多くの並行処理が行われているのをよく目にします。 お問い合わせ 同じデータキャリアに負荷がかかります。不適切なドライブ（SSD/NVMe ではなく HDD）は、多くの小さな I/O 操作を伴うチャッティアプリケーションに遭遇します。データベースのインデックスが不十分だと、スキャンで不必要に多くのブロックが読み込まれるため、この問題がさらに深刻になります。RAM キャッシュが不足していると、ホットデータセットの場合でも、システムは常にデータストレージにアクセスせざるを得ません。また、ライトバックキャッシュのない RAID レイアウトや、コントローラのファームウェアに欠陥がある場合も、遅延が顕著に増加します。.

待ち時間が長い場合の緊急措置

まず、過剰な部分を削減します。 パラレリズム ジョブ、ワーカー、データベース接続について。その後、ページキャッシュや InnoDB バッファプールなどのキャッシュの RAM 割り当てを増やします。RAID コントローラで（BBU を使用した）ライトバックキャッシュを有効にして、書き込みアクセスをより高速に確認します。バックアップおよび ETL プロセスをピーク時間から移動し、ログ書き込みアクセスを分離します。最後に、ディスクの効率を高めるために、ファイルサイズとバッチの粒度を最適化します。.

ストレージのアップグレード：HDD、SSD、NVMe のどれを選ぶべき？

を選ぶ。 テクノロジー ワークロードによる：小さなアクセスが多い場合は NVMe が必要で、大きなシーケンシャルストリームは SSD で十分対応でき、アーカイブデータは HDD に残します。最新の NVMe ドライブは、非常に低いレイテンシで IOPS を大幅に増加させ、iowait を大幅に短縮します。予算が重要な場合は、重要なデータベースを NVMe に、二次データを SSD/HDD に配置します。決定には、次のような比較が参考になります。 NVMe 対 SSD 対 HDD 技術、コスト、効果について。そうすることで、ユーザーが最も気にする待ち時間を短縮できるんだ。.

RAID とキャッシュを効果的に活用する

私は パフォーマンス RAID 10 は、読み取りおよび書き込みアクセスをより高速に処理し、冗長性を備えているため、よく使用します。RAID 5/6 は、書き込みのペナルティの影響が少ない、読み取り負荷の高いワークロードでよりよく使用します。バッテリーバックアップユニットは、コントローラで安全なライトバックキャッシュを可能にし、トランザクションを大幅に高速化します。さらに、Redis や Memcached は、メモリ内の頻繁に使用されるデータへのアクセスを高速化します。これにより、ドライブの負荷を軽減し、iowait を持続的に低減することができます。.

ファイルシステムとI/Oスケジューラを適切に選択する

私はデータ集約型の ワークロード XFS は、優れた並列処理と堅牢なメタデータ管理のため、よく使用します。ZFS は、チェックサム、スナップショット、圧縮が必要で、十分な RAM を用意できる場合に使用します。Ext4 は、多くの日常的なワークロードでは堅実ですが、非常に多くの inode や並列ストリームではパフォーマンスが低下する可能性があります。 SSD では Deadline または None/None タイプのスケジューラを使用しますが、HDD では CFQ タイプのスケジューラが有効です。リードアヘッドパラメータとキューの深さは、アクセスプロファイルに合わせて慎重に調整しています。.

階層化、QoS、優先順位

私は高速NVMeをホットな用途に組み合わせています。 データ SSD/HDD をコールドコンテンツ用、つまり真のストレージ階層化に使用します。これにより、あらゆる場面で最高のレイテンシに費用をかけることなく、重要な場面でその恩恵を享受することができます。QoS を使用して、帯域幅を大量に消費するバックグラウンドタスクを制限し、重要なトランザクションの安定性を維持します。実践的なアプローチとしては、以下の方法があります。ハイブリッドストレージおよびデータライフサイクルの明確なクラス。この組み合わせにより、iowait を低く抑え、負荷がかかったときに予期せぬ事態が発生するのを防ぎます。.

データベースとアプリケーションの整理

I/O を節約するために、 クエリ 厳格で適切なインデックスを設定します。N+1 クエリを排除し、結合を最適化し、チャッティートランザクションを削減します。接続プールは、ストレージを飽和させないようにサイズを設定します。書き込みバーストは、バッチ処理と非同期キューによって平準化し、ピーク時にすべてのリソースが同時に占有されるのを防ぎます。ログはまとめて書き込み、ローテーションを高速化し、一貫性の要件が許す限り、同期アクセスを最小限に抑えます。.

モニタリング戦略とスマートアラート

iowait、レイテンシパーセンタイル、avgqu-sz、IOPS、および スループット. 。チームが集中力を維持できるよう、短期的なピークではなく、トレンドに対してのみアラームを発します。原因を迅速に把握できるよう、ダッシュボードは容量、レイテンシー、エラー率ごとに分離しています。リクエストのトレースにより、ストレージに最も負荷がかかるパスがわかります。レイテンシーが重要なアプリケーションには、マイクロレイテンシーホスティング, 反応時間を全体的に短縮するため。.

実践：診断プロセスを段階的に進める

I/O 待ち時間を確実に特定するために、体系的な手順で進めます。まず、vmstat および sar を使用してシステム全体で、iowait が増加しているかどうか、また同時にコンテキストスイッチと SoftIRQ が顕著であるかどうかを調べます。次に、iostat -x を使用して、デバイスごとに r_await/w_await および avgqu-sz が上昇しているかどうかを確認します。次に、iotop/pidstat -d を使用して、最も多くのバイトを移動している、または最も長い待機時間を引き起こしているプロセスを特定します。.

tmpfs による簡易テスト：重要なプロセスを tmpfs/RAM ディスクでテスト的に繰り返します。レイテンシが大幅に低下した場合、そのデータキャリアがボトルネックとなっています。.
dmesg/smartctl を確認：エラー、リセット、再割り当てが頻繁に発生している場合は、ハードウェアまたはケーブル接続に問題があることを示しています。.
Read と Write の比較：書き込みレートが低い場合に w_await が長い場合は、コントローラキャッシュ、バリア設定、または同期負荷が原因である可能性が高いです。.

私は、アプリデザインと並行性、ファイルシステム/コントローラ、または物理的なデータキャリアを迅速に分離します。その後、すべてを盲目的に変更するのではなく、セグメントごとに最適化を行います。.

仮想化とコンテナ：ノイズの多い隣人を和らげる

VM およびコンテナでは、共有リソースを考慮して常に iowait を評価しています。オーバーブッキングされたハイパーバイザーは、ゲスト CPU が「空き」状態に見えても、変動するレイテンシを発生させます。仮想ブロックデバイス (virtio、エミュレートされた SCSI) およびネットワークストレージは、追加のレイテンシ層を追加します。私は、専用の IOPS/スループットを保証し、バーストの多いジョブを制限し、負荷の高いワークロードをホスト間で分散しています。.

cgroups/コンテナ：io.weight または io.max を設定して、サブジョブがストレージを「使い果たす」ことがないようにします。.
StorageClass/Volumes: ワークロードプロファイル（ランダム対シーケンシャル）に合わせてクラスを選択し、ログ/WAL をデータから分離します。.
VirtIO/NVMe：私は最新の準仮想化ドライバを好み、過負荷のない最大限の並列性を実現するために、vCPU ごとのキュー数をチェックしています。.

OSおよびカーネルのチューニングを慎重に行う

私は、測定可能な効果のある部分でオペレーティングシステムを調整します。過度に積極的なチューニングプロファイルは、多くの場合、新たな問題を引き起こすだけです。私は、保守的で文書化された手順から始め、その間に測定を行います。.

Writeback: vm.dirty_background_ratio および vm.dirty_ratio を制限して、カーネルがデータを早期に整然としたバッチで書き出し、バーストを平滑化するよう設定しています。.
先読み：デバイスごとにアクセスパターンに合わせて先読みを調整し（ランダムアクセスでは小さく、順次アクセスでは大きく）、不要なページが読み込まれないようにします。.
スケジューラ/blk-mq：NVMe では「none」/mq 最適化を使用し、HDD では必要に応じて公平性を重視します。デバイスごと、CPU ごとにキューの深さが適切かどうかを確認します。.
IRQ/NUMA：NVMe 割り込みをコアに分散（IRQ アフィニティ）、クロス NUMA トラフィックを回避、アプリとデータを「ローカル」に保持。.
CPUガバナー：私は通常、周波数変更によって追加のレイテンシが発生しないように、パフォーマンスに設定しています。.

マウントオプションとファイルシステムの詳細

適切なマウントオプションを使用することで、不要な I/O を削減し、重要な部分で一貫性を高めています。relatime/noatime を使用して、Atime の書き込みアクセスを削減しています。SSD では、ドライブが discard の影響を受けている場合、継続的な discard ではなく、定期的な fstrim を使用しています。ジャーナリング設定はワークロードに合わせて調整します。コミット間隔を短くすると耐久性が向上し、長くすると書き込み速度が低下します。.

Ext4: data=ordered は優れた標準設定であり、lazytime はメタデータの書き込み負荷を軽減します。.
XFS: メタデータの負荷がボトルネックにならないよう、ログパラメータ（サイズ/バッファ）に注意を払っています。.
ZFS：十分な ARC を計画し、レコードサイズをデータプロファイルに合わせて調整します。同期ポリシーは慎重に選択し、一貫した付加価値が得られる場合にのみ SLOG を追加します。.

ベンチマーキング：現実的であるべき、好条件だけを見るべきではない

実際のワークロードを反映した FIO プロファイルを使用して測定します。OLTP には 4k/8k、ストリームには 64k/1M のブロックサイズ、混合の読み取り/書き込み比率、アプリケーションに応じたキューの深さを使用します。「コールド」実行と「ウォーム」実行を区別し、SSD を事前調整し、最初の数秒だけでなく、定常状態も考慮しています。95/99 パーセンタイルを評価します。そこがユーザーエクスペリエンスの真価が発揮される場所だからです。.

シングルパス対マルチジョブ：まずデバイスごとにテストし、次に並行してテストして、スケーリングと干渉を理解します。.
キャッシュの影響：ページキャッシュを意図的にクリアするか、RAMヒットとデバイスのパフォーマンスを区別するために意図的に測定する。.
A/B：最適化前と最適化後を同じ方法で記録して、改善が間違いないようにします。.

暗号化、圧縮、重複排除

暗号化レイヤーと圧縮は I/O 特性に変化をもたらすことを考慮しています。dm-crypt/LUKS は、ハードウェアアクセラレーションなしではレイテンシを増加させる可能性がありますが、AES-NI を使用すると、CPU 負荷は多くの場合、適度なままです。軽量な圧縮（LZ4 など）は I/O 量を削減し、CPU を使用しても、特に低速のメディアでは、実質的に高速化することができます。重複排除メカニズムはメタデータ処理を増加させます。これはアーカイブシナリオには適していますが、レイテンシが重要な OLTP にはあまり適していません。.

バックアップ、メンテナンス、バックグラウンドジョブを管理

バックアップ、スキャン、ローテーションは、SLO に違反しないよう計画します。スループットを制限し、ionice/nice を設定し、長い実行を小さな継続可能なステップに分割します。スナップショットベースのバックアップは、ロックと I/O 負荷を軽減します。ログ処理には、バッファと専用キューを使用して、書き込みのピークが本番トラフィックに悪影響を与えないようにします。.

パスの分離：WAL/トランザクションログは高速メディアに、バルクデータは容量階層に保存。.
メンテナンスサイクル：定期的な fstrim、メンテナンスウィンドウでのファイルシステムチェック、およびコントローラのファームウェアを安定した状態に保つ。.
スロットリング：ETL/バックアップの帯域幅上限により、p99 レイテンシを安定的に維持。.

ストレージのキャパシティプランニングと SLO

ストレージは、容量だけでなく、レイテンシの予算も考慮して計画しています。重要なパスについては、p95/p99 の目標値を定義し、20～30 % のヘッドルームを確保しています。成長率と負荷プロファイルは四半期ごとに確認し、通常の負荷でキューの深さが増加した場合は、遅れることなく早めにスケーリングを行います。カナリア負荷を用いたロールアウト戦略は、フルトラフィックが発生する前に、新しいバージョンの I/O 動作をテストするのに役立ちます。.

日常的なトラブルシューティングのパターン

典型的な繰り返し発生する問題は、決まった方法で解決します。スループットが大きく変動する場合は、バルクジョブを抑制し、キャッシュを増やします。w_await が常に高い場合は、ライトバック、バリア、同期の強度を確認します。avgqu-sz が高い場合は、アプリ側の並列性を下げ、ホットスポットを複数のボリュームに分散します。個々のテナントだけが影響を受けている場合は、多くの場合、ストレージ全体ではなく、クエリやプールのサイズが問題となっています。.

測定値で決定事項を記録し、デプロイや設定変更と関連付けます。そうすることで、何が本当に効果があったのか、何が偶然だったのかが明確になります。.

簡単にまとめると

私は読んだ。 I/O待機 明確なシグナルとして：データキャリアが速度を決定します。適切な測定により、レイテンシ、IOPS、またはキューが制限要因であるかどうかを認識します。その後、キャッシュの増加、並列性の調整、クエリの最適化、ストレージのアップグレードなどの決定を行います。NVMe、ライトバックキャッシュを備えた RAID 10、適切なファイルシステム、および QoS により、待ち時間を大幅に短縮します。これにより、負荷が増加しても、io wait hosting を低く抑え、迅速な応答を実現します。.