ホームページ  >  記事  >  運用・保守  >  Linuxのロードアベレージ負荷問題の詳しい解説

Linuxのロードアベレージ負荷問題の詳しい解説

不言
不言転載
2019-03-12 17:24:102789ブラウズ

この記事では、Linux のロードアベレージ負荷問題について詳しく説明します。一定の参考値があります。困っている友人は参考にしてください。お役に立てれば幸いです。

ある面接で、面接官が「CPU 使用率は高くないのに、負荷 (平均負荷) が非常に高いです。問題をどのように見つけますか?」という質問をしました。

当時は Load の意味を理解していませんでしたが、面接官は、この指標は中断されない状態にあるプロセスが多いことを反映していると説明しました。私の過去のバックエンド開発の経験に基づいて、私は、システム内でより多くの IO ブロックがある可能性があると答えました。これは主にネットワーク IO の問題で発生します。コマンド netstat -tnp を使用して、TCP 接続に time_wait ステータスが多いかどうかを確認してください。 ..

わかっています 私の答えは非常に一方的だったので、後で見直してメモを取りました。

負荷平均とは

Linux に詳しい人は、top uptime コマンドを使用して負荷平均インジケーターを表示できることを知っています。

Use man uptime to view Load Average 説明:

システム負荷平均は、実行可能または中断不可能な状態にあるプロセスの平均数です。実行可能状態のプロセスは、 CPU、または CPU の使用を待機しています。中断不可能な状態のプロセスは、ディスクの待機など、何らかの I/O アクセスを待機しています。平均は 3 つの時間間隔にわたって取得されます。負荷平均は、システム内の CPU の数に対して正規化されていません。したがって、負荷平均 1 は、単一 CPU システムでは常に負荷がかかっていることを意味しますが、4 CPU システムでは、75% の時間アイドル状態であることを意味します。

重要な点を理解してください。平均負荷とは、次のものを指します。一定期間内に、システム内で実行可能状態および中断不可能な状態にあるプロセスの平均数を、平均アクティブプロセス数と呼びます。 CPU 使用率とは直接関係がないことに注意してください。

この記事で説明されているように、コマンド ps aux を使用してプロセスのステータス stat を表示します:

R ステータス、実行可能ステータス(実行ステータス) / 実行可能)、CPU を使用しているか CPU を待機しているプロセスの D 状態、中断不可能な状態 (無中断スリープ、ディスク スリープとも呼ばれます)、カーネルの重要なプロセスにあるプロセス状態であり、中断されません。

D なぜ状態を中断できないのでしょうか? たとえば、システムはデータの整合性を確保するために、ディスク デバイスがデータを返す前にハードウェア デバイスの I/O 応答を呼び出します。他のプロセスを中断する、または中断される 中断されると、ディスクデータとプロセスデータの間に不整合が発生しやすくなります。したがって、中断不可能 (D) 状態は、プロセスとハードウェア デバイスに対するシステムの保護メカニズムです。

アクティブなプロセスの平均数は、厳密に言えば、アクティブなプロセスの数の指数関数的な減衰平均です (特定の量の減少率はその値に比例します)。通常、単位時間当たりのアクティブなプロセスの数として理解できます。

CPU 使用率と負荷分散

CPU の観点から見ると、負荷平均は単位時間あたりの CPU を占有するプロセスの数のみを反映し、CPU 使用率はプロセスの数に直接関係しません。コマンド top vmstat を使用して CPU 使用率を確認できます。次のインジケーターがあります:

%us: ユーザー空間プログラムの CPU 使用率を示します (nice を通じてスケジュールされていません) %sy: CPU 使用率を示しますシステム空間の主にカーネルプログラム。 %ni: ユーザー空間内のプログラムと、nice によってスケジュールされたプログラムの CPU 使用率を示します。 %id: アイドル状態の CPU %wa: 実行中に CPU が IO を待機している時間 %hi: CPU によって処理されたハード割り込みの数 %si: CPU によって処理されたソフト割り込みの数 %st: 仮想マシンによって盗まれた CPU machine

適切な平均負荷を測定する方法

一般的に、負荷平均が CPU の数よりも低い場合、マシンのパフォーマンスはサービス要件を満たしています。それを超えているかどうかは問題ではありません。負荷平均は CPU 使用率を直接表すものではなく、IO ブロックの増加が原因である可能性があります。負荷平均が CPU 数の 70% を超えると、プロセスの応答が遅くなり、サービスの通常の機能に影響を与える可能性があります。

歴史的変化の観点から

一般的に、最高稼働時間は、1分、5分、15分の3つの時点での負荷平均指標を提供します。これは、システムの最近の状態変化の傾向を反映しています。実際の本番環境では、長期にわたる監視記録を作成する必要があります。平均負荷が CPU の 2 倍になるなど、異常な数値変化がある場合は、問題を分析して調査する必要があります。

2 種類の指標間の違いの包括的な分析

はバランスのとれた負荷と CPU 使用率に基づいており、次の考えられる状況が組み合わされます。

負荷平均は高、CPU 使用率が高い場合は、CPU を大量に使用するプロセス (スレッド) が実行されているか、CPU のスケジュールを待機しているプロセス (スレッド) が多数あります。負荷平均が高く、CPU 使用率が低い場合、IO -集中的なプロセスが実行されています。どちらも比較的低く、通常の負荷平均は低いです。CPU 使用率が高く、これは存在しません

シミュレーション ケースとツール

さまざまな組み合わせでケースを分析するにはどうすればよいですか?これら 2 つの指標、バランスされた負荷と CPU 使用率のうち、指標の変化の原因を見つけますか?

次の環境は Linux Arch 4.19 / 4 CPU / 8G メモリです。

ツール リスト

ストレス システム ストレス テスト ツール

sysstat パフォーマンス分析ツール パッケージ:

mpstat マルチコア CPU 解析パフォーマンス ツール、mp はマルチプロセッサ (マルチプロセッサ) を意味します。 pidstat プロセス パフォーマンス解析ツール、pid はプロセス ID を意味します。これは、プロセスの CPU、メモリ、I/O、およびコンテキスト切り替えインジケーターを表示するために使用されます

シミュレーション シナリオ

ストレスを使用すると、次のシナリオをシミュレートできます

CPU 負荷が高いプロセス

# 模拟一个进程, 对 cpu 使用率 100%,限时 600s
stress --cpu 1 --timeout 600

IO 集中型プロセス

stress -i オプション、sync() で回転する N 個のワーカーを生成

# 模拟一个进程不停的执行 sync
stress -i 1 --timeout 600
多数のプロセスのシナリオ
# 模拟16个进程, 对 cpu 使用率 100%,限时 600s
stress --cpu 16 --timeout 600

ツール インジケータ

mpstat -P ALL 5 は、すべての CPU を監視し、5 秒ごとに一連のデータを出力します。インジケーター %usr 使用率と %iowait IO ブロック時間に注意してください。これから、それが次のとおりであるかどうかを判断できます。 CPU 集中型または IO 集中型 pidstat - u 5 1 5 秒間隔の統計、CPU を使用したプロセスのデータ、指標 %usr 使用率、CPU 使用の %wait 待機時間に注意してください。これから判断できます。プロセス (スレッド) が多すぎるかどうか

#

以上がLinuxのロードアベレージ負荷問題の詳しい解説の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

声明:
この記事はsegmentfault.comで複製されています。侵害がある場合は、admin@php.cn までご連絡ください。