コンテンツにスキップ 
負荷平均 現在実行中またはCPU時間を待機中のプロセスの数を表示します。CPUの使用率（パーセント）は表示しません。この値を文脈なく読んだ人は、パニックに陥ったり、誤ったアップグレードを行ったりすることがよくあります。私は、この値を正しく解釈し、そこから適切なホスティングの決定を下す方法を説明します。.
中心点
- CPU%なし: Load は、実行キュー内のプロセスをカウントします。.
- コアあたり 考える：コア数で負荷を分割する。.
- I/O待機 負荷はCPUよりも頻繁に駆動します。.
- 1/5/15-分平均はピークを平滑化します。.
- コンテクスト 対策前：時間、仕事、交通量。.
ロードアベレージが実際に測定するもの
私はこの値を平均値として読み取ります。 プロセス, 、1分、5分、15分以上稼働しているもの、または実行キューで待機しているものを表示します。多くの人がこれをCPU負荷のパーセンテージと混同しますが、このカウンターはキューのみを認識し、計算時間は認識しません。1コアシステムでは、負荷1.0は持続的なフル稼働を意味しますが、4コアシステムでは同じ値でも負荷は低くなります。そのため、私は常に負荷を相対的に比較しています。 コア数値 そして、真の過負荷があるかどうかを評価します。15 分間の平均値は傾向を示し、一時的なピークと持続的な負荷を区別するのに役立ちます。.
高い値がしばしばI/Oの問題を示す理由
CPUがほとんど動作していないにもかかわらず、高い負荷が発生する場合があります。その場合、I/Oキューがブロックされます。 スレッド. top または htop を使用して %wa (I/O 待機) の割合を確認し、iotop を使用してストレージの速度を低下させているプロセスを確認します。 多くの場合、反応の遅いデータベース、バックアップジョブ、または過負荷のネットワークドライブが原因です。%wa が上昇する場合、CPU のアップグレードはあまり効果がありません。高速ストレージ、キャッシュ、および同期フラッシュの削減の方がより効果的です。詳細については、以下の記事をご覧ください。 I/O待機を理解する, 、待ち時間が長くなったときに参照するものです。.
誤解：負荷はCPU使用率と同じである
私は、パーセンテージの値を厳密に区別しています。 CPU およびロード平均をキューメトリックとして使用します。8 コアのサーバーでロードが 8 である場合は、すべてのコアが動作しており、待機状態がない場合、正常である可能性があります。 負荷がコア数を大幅に上回り、同時に 15 分間の曲線が上昇している場合は、深刻な状況と言えます。相関関係を確認するために、CPU%、I/O 待機、スケジューラ時間、およびプロセスリストを並べて表示します。これらの信号の相互作用によって初めて、マシンが計算中か、ブロック中か、あるいは単に多くの短命のジョブを処理中かがわかります。.
アラームではなく、適切に順位付けする
Cron、ログローテーション、バックアップによる短時間の負荷のピークは日常的に発生しており、必ずしも 故障. 私は、アラームを起動したり、容量を追加したりする前に、常に時間帯、継続時間、15 分ラインを評価します。しきい値はコア数でスケーリングします。例えば、負荷が 2× コア以上で数分間継続した場合にのみアラームを発します。コンテンツ管理システムで不規則なピークが発生した場合は、バックグラウンドタスクも追加でチェックします。WordPress については、以下のヒントが参考になります。 WP-Cronジョブと負荷. 。そうすることで、盲目的な反応を防ぎ、有益な対策を優先することができます。.
ホスティングの日常におけるロードアベレージの読み方
uptime を起動して概要を確認し、次に htop, プロセス、CPU 分配、RAM、I/O を確認します。15 分間の負荷が高いままの場合は、iotop または pidstat を使用して問題の原因を探します。データベース負荷の高いワークロードの場合は、クエリのレイテンシ、インデックス、キャッシュヒットを確認します。 Web サーバーでは、同時実行中の PHP ワーカーが多すぎるかどうか、また必要に応じて OpCache が機能しているかどうかを確認します。このルーチンにより、症状と原因を区別でき、費用がかかり、効果のないハードウェアのアップグレードを節約できます。.
| 指標 | 日常生活 | 警告信号（4コア） | 次のステップ |
|---|---|---|---|
| ロード 1分 | <4 | >8 3～5分以上 | トッププロセスを検証する |
| 15分間ロード | <3 | >6 上昇中 | 容量/アーキテクチャの計画 |
| CPU% | <80% | >95% 永久 | コード/ワーカーの最適化 |
| I/O待機 | <10% | >20% 先端 | ストレージ/キャッシュの確認 |
クリーンなホスティングモニタリングのためのツール
コンバイン 指標 エージェントのログとトレースを使って、原因を早く見つけるようにしてるよ。時系列データには、Prometheus や他のコレクターを使って、Grafana で視覚化してる。インフラストラクチャに関しては、チェックや柔軟なアラームルールには Zabbix、素早いダッシュボードには SaaS サービスが役立ってるね。 重要なのは、負荷、CPU%、RAM、スワップ、ディスクのレイテンシ、ネットワークを統一的に把握すること。共通の時間軸がなければ、負荷値の解釈は断片的なものにとどまってしまう。.
| カテゴリー | 例 | 強み |
|---|---|---|
| オープンソース | ザビックス | チェック、エージェント、アラームロジック |
| 時系列 | プロメテウス | プルモデル、PromQL |
| 視覚化 | グラファナ | ダッシュボード、アラート |
| SaaS | Datadog | 統合、APM |
持続的な高負荷での最適化
私は最大の痛みから始めます：ゆっくりとした クエリ, 、I/O パスがブロックされている、または同時作業者が多すぎる。データベースインデックス、接続プール、Redis や Memcached などのクエリキャッシュは、待ち時間を大幅に短縮します。アプリケーションレベルでは、ページ、フラグメント、オブジェクトのキャッシュ、およびクリーンなキュー処理により、ソースの負荷を軽減します。 システムでは、vm.swappiness を適切に設定し、Huge Pages をチェックし、サービスに適切な制限を設定します。ソフトウェア側の対策が尽くされた場合にのみ、垂直方向（RAM/CPU の増設）または水平方向（ロードバランサーによるインスタンスの増設）の拡張を行います。.
マルチコアシステムにおける負荷平均
私は常に負荷を相対的に計算します。 コア: ロード 16 は 16 個の物理コアでは問題ありません。ハイパースレッディングにより論理 CPU は 2 倍になりますが、実際のパフォーマンスは必ずしも直線的に向上するとは限りません。そのため、私はレイテンシも追加で評価しています。 コンテナや VM では、CPU シェア、CFS クォータ、および制限が影響し、一見「正常」に見える値を歪めることがあります。CPU スロットリングとスケジューラの待ち時間を確認することで、厳しい制限と真の容量の問題を区別することができます。明確な判断を下すために、15 分間の曲線をトレンドの指標として活用しています。.
共有ホスティング、隣人、そして隠れたボトルネック
共有環境では、その影響は 隣人 多くの場合、自身のアプリよりも強力です。そのため、CPU スティール、レディ時間、ストレージ競合も監視し、外部からの負荷を検知しています。コアが「スティール」されると、自身の最適化にもかかわらず、負荷はさらに増加します。判断の基準として、以下のガイドラインを利用しています。 CPU スティールタイム 必要に応じて専用リソースを計画します。これにより、ボトルネックに陥ることなく、予測可能なパフォーマンスを確保します。.
トレンド、しきい値、アラームを正しく設定する
私はしきい値を コア また、アラームがピークごとに作動しないようにヒステリシスを設定しています。4 コアの場合、アラームは負荷が 8 以上、数分間継続した場合に作動し、15 分間のトレンドで確認します。メンテナンスウィンドウとバッチ時間は評価から除外し、チャートが誤った情報を伝えないようにしています。 さらに、固定値を永続化するのではなく、自身の過去の平均値と比較した異常検出を利用しています。これにより、誤警報でチームを疲れさせることなく、実際の変化に早期に対応することができます。.
Linux が実際に負荷をカウントする方法
必要に応じて内部を確認します。カーネルは、実行キューの長さを平均化し、アクティブに実行中のスレッド（状態「R」）だけでなく、 途切れることのない睡眠 （「D」、ほとんどの場合 I/O 待機状態）。これは、CPU 使用率が低いにもかかわらず負荷値が高い理由を正確に説明しています。多くのスレッドが、低速のディスク、ネットワーク、または NFS アクセスでカーネル内でブロックされているのです。 /proc/loadavg 3つの平均値に加え、「実行中/全」スレッドと最後のPIDが表示されます。ゾンビは考慮されませんが、カーネルスレッドとユーザースレッドは同等に反映されます。 多くの短命なタスク（ビルド、ワーカー）があるシステムでは、当然ながら 1 分間の値はより大きく変動しますが、15 分間の値は安定性の指標となります。.
私にとって重要なのは、「負荷」を「待ち時間」と解釈することです。負荷がコア数を大幅に上回ると、待ち行列が発生します。短時間のジョブであれば問題はありませんが、同時にリクエストのレイテンシが増加すると、システムは過負荷状態になります。そのため、私は常に負荷を ランタイムメトリクス（Req-Latency、ttfb）を使用して、キューを数値だけでなく、効果に基づいて評価します。.
メモリ圧迫、スワップ、および隠れたブロック
私は、以下のケースで常に高い負荷値を見かけることが多いです。 ストレージの圧力. ページキャッシュが縮小したり、kswapd がページを移動したりすると、プロセスは待機状態になります。スワッピングは I/O を発生させ、すべての処理を遅くします。私は vmstat (si/so)、メジャーページフォールト、, /proc/meminfo （キャッシュ、ダーティ、ライトバック）を監視し、I/O レイテンシが同時に増加するかどうかを確認します。CPU% が中程度でディスクの「待機」が増加している場合に負荷が高い場合は、RAM が不足しているか、データセットがキャッシュに収まらないことを明確に示していると思います。.
私は段階的に対応します。まず、RAM のホットスポット（大規模なソート、キャッシュされていないクエリ、巨大な PHP 配列など）を特定し、次にキャッシュを強化し、 vm.swappiness メモリが早すぎるタイミングで置換されないように設定する。 スワップを完全に無効にするのは、ほとんどの場合賢明ではありません。小規模で高速なスワップ（NVMe）を規律正しく使用することで、OOM キラーのピークを回避できます。ライトバックがボトルネックになる場合は、同期の波（バッチ処理、ジャーナリングオプション、非同期フラッシュ）を緩和し、同時書き込み数を減らします。.
コンテナ、Cgroups、CPU スロットリング
コンテナでは、Load を以下の観点から解釈しています。 cgroups. CFSクォータは、期間ごとのCPU時間を制限します。制限に達すると、コンテナは単に 抑制された になります。私は確認します。 cpu.max (cgroup v2) または. cfs_quota_us/cfs_period_us (v1) およびスロットルカウンタ (cpu.stat）。「throttled_time」が上昇する場合、その原因は計算能力の不足ではなく、ハードリミットです。Kubernetes では、「リクエスト」（スケジューリング）と「リミット」（スロットリング）を厳密に区別しています。誤って設定されたリミットは、人為的なキューを生成します。.
CPUアフィニティとNUMAも状況に影響を与えます。スレッドが少数のコアにピン留めされたり、NUMAノードに駐車されたりすると、グローバルCPU%は問題ないように見えても、ローカルで負荷が滞留する可能性があります。 私は、ホットスレッドを意図的に分散し、IRQ バランスをチェックし、コンテナがすべて同じ物理コアに押し込まれないように注意しています。これにより、ハードウェアをアップグレードすることなく、待ち時間を削減しています。.
迅速な意思決定チェックリスト
- 相対的な負荷 コア 評価する（負荷/コア ≈ 1 は良好、≫1 は危険）。.
- CPU% そして I/O 待機 対比：箱は計算しますか、それとも待ちますか？
- 15分-トレンドを確認する：持続的な過負荷対短時間のピーク。.
- トッププロセス および状態 (R/D/S/Z) を確認してください。D 状態が多い場合、I/O のボトルネックが発生しています。.
- ディスクのレイテンシ, 、キューの深さ、%util を測定する。NFS/ネットワークパスも一緒にチェックする。.
- RAM: ページフォールト、スワップアクティビティ、kswapd – メモリの負荷を軽減する。.
- 限界 コンテナ/VM で確認：クォータ、共有、スティール、スロットリング。.
- コンカレンシー スロットリング：ワーカー/スレッド、キュー、バックプレッシャー。.
- ピーク時 移行：Cron、バックアップ、インデックス、ETL。.
- 再調整, 、再度測定してください – ハードウェアよりも効果が優先されます。.
ホスティングにおける具体的なチューニングの例
Web/PHPスタックでは コンカレンシー 最大のレバレッジ。PHP‑FPMでは現実的な設定を採用しています。 pm.max_children, リクエストがデータベースを同時にオーバーフローしないようにするためです。nginx または Apache では、同時アップストリーム接続を制限し、Keep‑Alive を適切に有効にし、静的アセットを積極的にキャッシュします。OpCache はウォームアップストームを防止し、オブジェクトキャッシュ (Redis/Memcached) はクエリ負荷を大幅に軽減します。.
データベースについては、私は以下から始めます。 インデックス作成 そして計画を立てます。盲目的に接続数を増やすのではなく、接続プールを利用し、同時に行われる高コストのクエリを制限します。バッファプールのヒット率、ロックの待機時間、一時テーブルのスピルを監視します。大規模なレポートや移行ジョブは非同期でバッチ処理されます。5分間200%の負荷とその後停止するよりも、60%の負荷が一定である方が望ましいです。.
メモリを大量に消費するランナー（画像/動画処理など）については、ホストごとに同時ジョブの上限を設定しています。私は nice そして ionice, バッチプロセスがインタラクティブなレイテンシを損なわないようにするためです。高速の NVMe ディスクでは、スケジューラの構成をスリムに保ち、十分なキュー深度を確保し、チャッティシンクを回避しています。これにより、D ステートの雪崩が解消され、CPU% を上げることなく負荷が低下します。つまり、マシンの待機時間が短縮されるのです。.
ビルドおよびバッチワークロードを計画的に実行
コンパイルやレンダリングでは、負荷は ジョブの並列性. 私は選びます -j 意識的：コア×（0.8～1.2）は良いスタートですが、私は RAM 1つ – 負荷のピークによるスワップの嵐よりも、並行するジョブは少ないほど安定している。アーティファクトキャッシュ、インクリメンタルビルド、専用I/Oボリュームにより、多数の小さなファイルによってDステートがキューを肥大化させることを防止する。.
バッチウィンドウは負荷が軽くなるように計画します。ローテーション、バックアップ、ETL、再インデックスは、すべて正時に実行されるのではなく、段階的に実行されます。ワークキューにはバックプレッシャーがかけられます。スロットが空きがある場合にのみ新しいジョブが実行され、「ファイア・アンド・フォーゲット」方式は採用されません。これにより、負荷とレイテンシを制御可能にし、ピークを予測可能にします。.
PSI：早期警報システムとしての圧力失速情報
従来のロードに加えて、私は 圧力失速情報 (PSI) Linux の /proc/pressure/cpu, .../io そして .../memory. PSI は、タスクの所要時間を表示します。 集団的に 待つ必要があった – 過負荷に理想的 早い CPU% が中程度であるにもかかわらず、CPU プレッシャーが数分間上昇し続ける場合、ランキューが滞っていることがわかります。I/O プレッシャーでは、個々の iotop 値が無害に見える場合でも、ストレージのレイテンシがシステム全体に影響を与えているかどうかを確認できます。.
私は PSI と 15 分間の負荷を組み合わせています。両方が上昇している場合は、真の飽和状態にあると言えます。負荷のみが上昇し、PSI は変化がない場合は、ユーザーには気付かない多くの短いジョブが実行されている可能性があります。これにより、より正確なアラームとより適切な判断が可能になります。制限を引き上げ、ジョブの負荷を分散し、ボトルネックが測定できる場所でハードウェアを強化します。.
持ち帰れる簡単な概要
私はそれを読みます。 負荷 決して単独で評価するのではなく、コア、I/O 待機、CPU%、15 分間の曲線などのコンテキストで評価します。高い値については、ストレージとネットワークのレイテンシを確認してから判断します。なぜなら、多くの場合、実際のボトルネックはそこに存在するからです。 対策としては、クエリ、キャッシュ、ワーカー、制限など、目に見える効果のある手段を優先し、その後にハードウェアを検討します。共有環境では、スティールなどの寄生効果を確認し、必要に応じて専用リソースを計画します。これらのルールに基づいて、冷静かつ確固たる判断を下し、ホスティング設定の信頼性と速度を維持しています。.
