負荷（コンピューティング）

UNIX コンピューティングでは、システム負荷はコンピュータ システムが実行する計算作業の量の尺度です。負荷平均は、一定期間の平均システム負荷を表します。通常、これは最後の 1 分、5 分、15 分間のシステム負荷を表す 3 つの数値の形式で表示されます。

すべての Unix および Unix ライクなシステムは、カーネル内で 3 つの「負荷平均」数値の無次元メトリックを生成します。ユーザーは、次のコマンドを実行することで、Unix シェルから現在の結果を簡単に照会できます。 uptime

$稼働時間
14:34:03 10:43 起動、ユーザー 4 人、負荷平均: 0.06、0.11、0.09

wおよびコマンドtopは、さまざまなグラフィカル ユーザーインターフェイス ユーティリティと同様に、同じ 3 つの負荷平均数値を表示します。

Linux カーネルに基づくオペレーティング システムでは、ファイルを読み取ることでこの情報に簡単にアクセスできます/proc/loadavg。

この種の情報を詳細に調査するために、Linuxのファイルシステム階層標準に従って、アーキテクチャに依存する情報がファイル上で公開されています/proc/stat。^{[1] [2] [3]}

アイドル状態のコンピュータの負荷数は 0 です (アイドル状態のプロセスはカウントされません)。CPUを使用しているか、CPUを待っているプロセス(準備完了キューまたは実行キュー) ごとに、負荷数は 1 ずつ増加します。終了したプロセスごとに、負荷数は 1 ずつ減少します。ほとんどの UNIX システムでは、実行中( CPU 使用中) または実行可能(CPU 待機中)状態のプロセスのみをカウントします。ただし、Linux では割り込み不可能なスリープ状態 (通常はディスクアクティビティを待機中) のプロセスもカウントされるため、ビジー状態または停止した I/O システムのせいで多くのプロセスがI/Oでブロックされたままになると、結果が著しく異なる場合があります。 ^[4]たとえば、これにはNFSサーバーの障害や低速なメディア( USB 1.x ストレージ デバイスなど) が原因でブロックされているプロセスが含まれます。このような状況では負荷平均が上昇する可能性がありますが、これは CPU 使用率の実際の増加を反映しません (ただし、ユーザーが待機しなければならない時間はわかります)。

システムは負荷平均を負荷数の指数減衰/加重移動平均として計算します。負荷平均の3つの値は、システム動作の過去1分、5分、15分を指します。^[5]

数学的に言えば、3 つの値はすべて、システムの起動以降のすべてのシステム負荷を常に平均化します。これらはすべて指数関数的に減少しますが、減少する速度は異なります。それぞれ 1、5、15 分後にeずつ指数関数的に減少します。したがって、1 分間の負荷平均は、最後の 1 分間の負荷の 63% (より正確には、1 - 1/ e ) と、最後の 1 分間を除いた起動以降の平均負荷の 37% (1/ e ) で構成されます。5 分間および 15 分間の負荷平均では、同じ 63%/37% の比率がそれぞれ 5 分間および 15 分間にわたって計算されます。したがって、1 分間の負荷平均には、過去のアクティビティの 37% が含まれるため、最後の 60 秒間のアクティビティのみが含まれるというのは技術的に正確ではありませんが、主に最後の 1 分間が含まれると述べるのは正しいです。

CPU にバインドされた単一 CPU システムの場合、負荷平均はそれぞれの期間におけるシステム使用率の尺度として考えることができます。複数の CPU を備えたシステムの場合、比較可能な尺度を得るには、負荷をプロセッサの数で割る必要があります。

たとえば、シングル CPU システムでの負荷平均「1.73 0.60 7.98」は次のように解釈できます。

• 最後の 1 分間に、システムは平均 73% 過負荷になりました (実行可能なプロセスは 1.73 個で、平均して 0.73 個のプロセスが単一 CPU システムの順番を待つ必要がありました)。
• 過去 5 分間、CPU は平均して 40% の時間アイドル状態でした。
• 最後の 15 分間に、システムは平均で 698% 過負荷になりました (実行可能なプロセスは 7.98 個あり、平均して 6.98 個のプロセスが単一 CPU システムの順番を待つ必要がありました)。

これは、このシステム (CPU、ディスク、メモリなど) が 1.73 倍高速であれば、最後の 1 分間にスケジュールされたすべての作業を処理できた可能性があることを意味します。

4 つの CPU を備えたシステムでは、負荷平均が 3.73 の場合、平均して 3.73 個のプロセスが実行準備完了であり、各プロセスが CPU にスケジュールできることを示します。

現代の UNIX システムでは、負荷平均に関するスレッドの扱いはさまざまです。一部のシステムでは、負荷平均の計算のためにスレッドをプロセスとして扱います。つまり、実行を待機している各スレッドは負荷に 1 を追加します。ただし、他のシステム、特にいわゆるM:N スレッドを実装しているシステムでは、負荷の目的でプロセスを 1 回だけカウントする (スレッドの数に関係なく) か、ユーザースレッド スケジューラによってカーネルに現在公開されているスレッドのみをカウントする (プロセスに設定されている同時実行レベルに依存する場合があります) などの異なる戦略を使用します。Linux は、各スレッドを個別にカウントして負荷に 1 を追加するようです。^[6]

Ferrari ら^[7]が実施したさまざまな負荷指標の比較研究では、CPU キューの長さに基づく CPU 負荷情報は、CPU 使用率と比較して負荷分散に非常に優れていることが報告されています。CPU キューの長さの方が優れている理由は、ホストの負荷が高い場合、CPU 使用率は 100% に近くなる可能性が高く、使用率の正確な負荷レベルを反映できないためと考えられます。対照的に、CPU キューの長さは CPU の負荷量を直接反映できます。たとえば、キュ​​ーに 3 つのプロセスがあるシステムと 6 つのプロセスがあるシステムの 2 つは、明らかに異なりますが、どちらも使用率が 100% に近くなる可能性が非常に高いです。^{[オリジナル研究? ]}

Linux システムでは、負荷平均は各クロック ティックで計算されるのではなく、HZ 周波数設定に基づいて各クロック ティックでテストされる変数値によって決定されます。この設定は、カーネル クロック ティック レートをヘルツ(1 秒あたりの回数) で定義し、10 ミリ秒のティックに対してはデフォルトで 100 になります。カーネル アクティビティは、このティック数を使用して時間を計ります。具体的には、負荷平均を計算する timer.c::calc_load() 関数は、LOAD_FREQ = (5*HZ+1)ティックごとに、つまり約 5 秒ごとに実行されます。

符号なしロングアヴェンラン[ 3 ]  

static inline void calc_load ( unsigned long ticks ) { unsigned long active_tasks ; /* 固定小数点 */ static int count = LOAD_FREQ ;     

      
       

   count -= ticks ; if ( count < 0 ) { count += LOAD_FREQ ; active_tasks = count_active_tasks (); CALC_LOAD ( avenrun [ 0 ], EXP_1 , active_tasks ); CALC_LOAD ( avenrun [ 1 ], EXP_5 , active_tasks ); CALC_LOAD ( avenrun [ 2 ], EXP_15 , active_tasks ); } }  
       
        
        
        
        
        
   

avenrun 配列には、1 分、5 分、15 分の平均値が含まれます。CALC_LOADマクロとそれに関連する値は、sched.h で定義されています。

#define FSHIFT 11		 /* 精度のビット数 */ 
#define FIXED_1 (1<<FSHIFT)	 /* 固定小数点として 1.0 */ 
#define LOAD_FREQ (5*HZ+1)	 /* 5 秒間隔 */ 
#define EXP_1 1884		 /* 固定小数点として 1/exp(5sec/1min) */ 
#define EXP_5 2014		 /* 1/exp(5sec/5min) */ 
#define EXP_15 2037		 /* 1/exp(5sec/15min) */

#define CALC_LOAD(load,exp,n) \ 
   load *= exp; \ 
   load += n*(FIXED_1-exp); \ 
   load >>= FSHIFT;

負荷平均の「サンプリング」計算は、ある程度一般的な動作です。FreeBSD も、5 秒ごとに値を更新します。通常、間隔は正確ではないため、特定の瞬間に起動するようにスケジュールされているプロセスは収集されません。^[8]

Linuxメーリングリストの投稿では、+1ティックではこのような収集によるモアレアーティファクトを回避するには不十分であると考えられており、代わりに4.61秒の間隔が提案されています。^[9]この変更はAndroidシステムカーネルでは一般的ですが、使用される正確な式ではHZが100であると想定されています。^[10]

システム パフォーマンスを評価するためのその他のコマンドは次のとおりです。

• uptime – システムの信頼性と負荷平均
• top – システム全体のビュー
• vmstat – vmstat は、実行可能またはブロックされたプロセス、メモリ、ページング、ブロック I/O、トラップ、CPU に関する情報を報告します。
• htop – インタラクティブなプロセスビューア
• dool（旧称dstat）、^[11] atop  – プロセス、メモリ、ページング、ブロックI/O、トラップ、CPUアクティビティに関する既存のすべてのリソースデータを相関させるのに役立ちます。
• iftop – インターフェースごとのインタラクティブなネットワークトラフィックビューア
• nethogs – プロセスごとのインタラクティブなネットワーク トラフィック ビューア
• iotop – インタラクティブI/Oビューア^[12]
• iostat – ストレージI/O統計用
• netstat – ネットワーク統計用
• mpstat – CPU統計用
• tload – 端末の負荷平均グラフ
• xload – Xの負荷平均グラフ
• /proc/loadavg – 負荷平均を含むテキストファイル

• CPU使用率

• Brendan Gregg (2017 年 8 月 8 日)。「Linux の負荷平均: 謎を解く」 。2018年1 月 22 日閲覧。
• Neil J. Gunther . 「UNIX 負荷平均 - パート 1: 仕組み」(PDF)。TeamQuest。2009年8 月 12 日閲覧。
• Andre Lewis (2009 年 7 月 31 日)。「Linux CPU 負荷を理解する - いつ心配すべきか?」。2011 年7 月 21 日閲覧。交通を例にとったイラストを使った説明。
• Ray Walker (2006 年 12 月 1 日)。「負荷平均の調査」。Linux Journal。2011年7 月 21 日閲覧。
• Karsten Becker。「Linux OSS 負荷監視ツールセット」。LoadAvg。