なぜ低い平均利用率でも忙しいホームサーバーを隠せるのか？

低い平均使用率は、時間、CPUコア、プロセス、リソースタイプを少数の数値に圧縮するため、忙しいホームサーバーを隠すことがあります。サーバーは1分の大半をアイドルで過ごしても、短い5秒間のバースト中にすべてのインタラクティブリクエストを一時停止させることがあります。

同じミスマッチは、1つのコアが飽和し、タスクがストレージ待ち、スレッドがロックでブロック、メモリ回収が割り当てを遅延、またはごく一部のリクエストだけが非常に高いレイテンシを経験するときに現れます。マシンは重要なリクエストが待機しているときに忙しく感じられ、総CPUやRAMが100%表示されているときだけではありません。

なぜ長いサンプリングウィンドウは短い忙しい期間を消してしまうのか？

監視システムは一般的にリソースカウンターを15秒、1分、またはそれ以上の期間で平均化します。長いサンプリングウィンドウは短いCPUスパイクを隠します。なぜなら、短時間のフルキャパシティは長いアイドル期間と合わさると控えめな数値になるからです。

6秒間100%のCPU使用率で、残りの54秒はほぼアイドルのサーバーは、1分間の平均値が低く報告されます。その6秒間に到着したウェブリクエストは完全なキューを経験し、後のアイドル時間はグラフを希釈するだけです。

ダウンサンプリングが効果を増幅します。高解像度のメトリクスはバーストを捉えますが、1時間ごとのダッシュボードは平均、最小、最大、あるいは平均値1点のみを保存します。

なぜ1つのコアが飽和しているのに総CPU使用率は低く見えるのか？

総CPU使用率はすべての論理プロセッサの活動を平均化しますが、CPU使用率は停止した実行を隠すことがあります。シングルスレッドのアプリやホットなカーネルキューは限界に達しても、残りのコアはアイドルのままです。

8コアのシステムでは、1つのコアが完全に使用されていると、全CPU容量の約8分の1に見えます。データベースの書き込み、イベントループ、圧縮スレッド、またはsoftirqパスがそのコアに依存している場合、アイドルコアを増やしても直列化された段階は短縮されません。

周波数、サーマルスロットリング、ハイパースレッディング、スケジューラ移行、メモリスタールも、1パーセントポイントがどれだけの作業量を表すかに影響します。コアごとの使用率と完了した作業量の方が、ホスト全体の単一数値よりも有益です。

なぜCPUはアイドル状態に見えるのにアプリケーションはストレージ待ちになるのか？

Linuxのロードは単なるCPU使用率ではありません。ロードアベレージにはI/O待ちのタスクも含まれます。そのため、ディスク、ネットワークファイルシステム、ストレージコントローラでブロックされたスレッドがシステムを停止しているように感じさせることがあります。

プロセッサは利用可能でも、読み取り、ジャーナルコミット、データベースフラッシュ、メタデータ操作、ネットワークストレージの応答が完了するまでアプリケーションは続行できません。したがってCPUのアイドル時間はボトルネックの結果であり、リクエストに十分なリソースがある証拠ではありません。

デバイスのレイテンシ、キューの深さ、I/O待ち、ブロックされたタスク、ファイルシステムの挙動、ネットワークストレージのRTTを確認してください。多くの小さな同期操作で構成されるワークロードでは、低いMB/s値でも飽和を除外できません。

ロック、プール、キューはどのように高いCPUを使わずに作業を生み出すのか？

スレッドが存在しリクエストがアクティブでも、共有状態を待っているためCPUを消費していないことがあります。ロック競合はCPUスパイクなしにレイテンシを上げることがあります。これは一つのトランザクションが他の操作の進行を妨げる場合に起こります。

接続プール、ファイルロック、データベーストランザクション、ワーカーキュー、ソケットバックログ、アプリケーションセマフォはすべて有限の同時実行性を持ちます。すべてのスロットが占有されているプールは、タスク自体が待機中であっても飽和しています。

これがキューの長さと待ち時間が重要な理由です。利用率は作業を行うリソースを示し、飽和はすぐに開始または完了できない需要を示します。

なぜメモリプレッシャーはRAMが枯渇していないのにアプリを停止させるのか？

コンテナは自身の制限内で空きメモリがあっても、ホストはすでにプレッシャー下にあることがあります。カーネルが新しい割り当てを満たす前にページを解放しなければならない場合、直接メモリリクレイムがアプリケーションスレッドを停止させることがあります。

ダッシュボードはメモリ不足イベントを示さなくても、リクエストスレッドがリクレイムに入ったり、ダーティページの書き戻しを待ったり、最近追い出されたページでフォルトしたり、別のワークロードによって削除された作業セットを再構築したりすることがあります。

メモリプレッシャー、主要なページフォルト、スワップアクティビティ、リクレイム時間、ダーティページの書き戻し、キャッシュの再フォルトを測定します。重要な問いは、使用中のメモリバーが視覚的に満杯かどうかではなく、タスクがメモリのために停止しているかどうかです。

どの指標が隠れたビジーステートを明らかにするのか？

ユーザーは分布の端にある遅いリクエストを体験するため、平均レイテンシは最も遅いリクエストを隠すことがあります。平均応答時間だけでなく、パーセンタイル、最大値、リクエストレベルのトレースを追跡してください。

高解像度のコアごとのCPU、実行キュー、I/Oレイテンシ、ブロックされたタスク、プレッシャーストール情報、メモリ再取得、接続プール占有率、ロック待ち、およびアプリケーションのp95またはp99レイテンシを組み合わせます。同じタイムラインに合わせて、1つの待機パスをレイヤー間で追跡できるようにします。

短い接続は固定セットアップ作業を繰り返します。遅い瞬間の完了した作業と待機時間を測定してください。穏やかな長期平均では、どのリソースがそのリクエストの進行を妨げたか説明できません。

よくある質問

LinuxのロードアベレージはCPU利用率と同じですか？

いいえ。ロードアベレージには実行可能なタスクと割り込み不能なスリープ中のタスクが含まれ、これには一般的にI/O待ちのスレッドが含まれます。

総CPUが20％でもCPUボトルネックを意味しますか？

はい。1つのコア、1つのスレッド、または1つの直列化されたカーネルパスが飽和している間、他のコアはほとんどアイドル状態のままであることがあります。

スパイクが消えた後、なぜサーバーは遅く感じるのですか？

キューはまだ排出中かもしれませんし、キャッシュはウォーミングアップが必要かもしれません。ダーティデータはまだフラッシュ中かもしれませんし、リトライが元の停滞中に蓄積されているかもしれません。

CPU利用率に代わる単一の指標は何ですか？

単一の指標では不十分です。CPU、メモリ、ストレージ、ネットワーク、およびアプリケーション自身のリクエストパスについて、利用率と飽和度およびレイテンシの信号を組み合わせてください。

最終的な結論

低い平均値はホームサーバーに即時の容量があることを証明しません。時間の集約はバーストを消し去り、総CPUは一つのホットコアを隠し、アイドル状態のプロセッサはストレージを待ち、ロックやメモリの再取得は劇的な利用率のバーなしにリクエストを停滞させることがあります。高解像度の飽和度指標とテールレイテンシは、サーバーが忙しいと感じたときに重要な作業が実際に進行できたかを明らかにします。