Solaris 10の平均負荷を説明する
Linuxの平均負荷を理解していますが、アプリを実行しているレガシーSolaris 10マシンの平均負荷に少し不思議です。負荷平均は信じられないほど高いようです。これが出力です。
[netcool1 (root)/]$ uptime
11:49am up 580 day(s), 10:51, 3 users, load average: 35.50, 38.54, 39.03
[netcool1 (root)/]$ uname -a
SunOS netcool1 5.10 Generic_139555-08 Sun4u sparc SUNW,Sun-Fire-V245
[netcool1 (root)/]$ psrinfo -v
Status of virtual processor 0 as of: 01/11/2012 11:52:52
on-line since 06/10/2010 01:58:29.
The sparcv9 processor operates at 1504 MHz,
and has a sparcv9 floating point processor.
Status of virtual processor 1 as of: 01/11/2012 11:52:52
on-line since 06/10/2010 01:58:27.
The sparcv9 processor operates at 1504 MHz,
and has a sparcv9 floating point processor.
[netcool1 (root)/]$
2プロセッサシステムで負荷平均を35にする方法はわかりません。それは私には信じられないほど高いようです。 topでプロセスを表示すると、システムは約60〜70％アイドルです。誰かがこれを説明してくれませんか？
vmstat 10 6
kthr memory page disk faults cpu
r b w swap free re mf pi po fr de sr rm s0 s2 -- in sy cs us sy id
3 0 0 8747008 5562704 865 1866 188 63 63 0 0 -0 9 40 0 762 8588 1495 26 8 66
0 0 0 7715256 5068016 73 23 5 17 17 0 0 0 110 66 0 1135 3888 9855 59 12 30
0 0 0 7717936 5069128 0 5 0 6 6 0 0 0 100 4 0 1071 3273 4191 62 6 32
0 0 0 7717952 5027912 0 11649 0 5 5 0 0 0 115 21 0 1017 26370 3260 32 15 53
102 1 0 7717952 4979088 0 1 0 0 0 0 0 0 112 4 0 900 3464 7683 15 9 76
0 0 0 7717952 4978936 0 1 0 0 0 0 0 0 105 4 0 886 3379 8698 19 9 72
「ロード」は通常、vmstatの最初の列の平均です（列r、実行キュー）。最初のロードは平均で1分、2番目は5分、最後は15分です。ご覧のように、システムでvmstatがプロセッサを使用するためにウェイクアップしたスレッドがおそらく102あることを報告しました（おそらくいくつかの大規模マルチスレッドアプリケーション）。
しかし、心配はありません。確かにこのワークロードのバーストは処理されており、実行キューは次のプローブでゼロに戻って続行しました。 V245には2つのプロセッサがあり、それぞれシングルコアとシングルスレッドであるため、同時に2つのスレッドを実行できます（つまり、r = 2は、プロセッサ時間を待機する必要のあるスレッドがないことを意味します）。
統計的に、これはできますは平均35に変換されますが、ご覧のとおり、この値は実際のシステムの使用状況についてはほとんど意味がありません。 Adageは、「あります種類の嘘：嘘、のろわれた嘘、統計」と言い、これは結論として役立つと思います。
古いソラリスでは、load-averageは実行可能なスレッドと実行中のスレッドの平均数です。言い換えると、これは、CPUで実行されているスレッドの数に、CPUを待機している実行キュー内のスレッドの数を加えたもので、時間の平均です。
つまり...直前の1秒間に10個のスレッドの処理を完了し、さらに5個の処理待ちがあったCPUは、15を示します。
対照的に...
Linuxの負荷平均は、CPUの「過負荷」として計算されます。つまり、最後の期間中に、完了したスレッド数のうち、CPUタイムを待っていたスレッド数が計算されます。 （パーセンテージとして）
つまり...直前の1秒間に10個のスレッドの処理を完了し、処理を待機しているCPUがさらに5個あるCPUは0.5
Solaris 10では...彼らは式を少し変更しました...そしてそれが何を伴うのか100％確信はありませんが、かなり近いはずです。
かなり遅い返信ですが、受け入れられた回答にはまだ誤ったステートメントがあり、要点の一部が欠落しており、OSによって報告されたものを信頼しない理由はここにありませんが、統計が存在することを示唆しています。
以下は、観察された統計の詳細な説明です。
uptimeおよびその他のコマンドによって報告される負荷平均は、平均の1、5、および15分の変動平均ですCPU（実行キュー）を待機しているスレッドの数と、CPUで実際に実行されているスレッドの平均数。
アイデアは、多くの場合非常に不規則である実行キューのサイズと実行中のプロセス数の表示をスムーズにすることです。
実行キューのサイズは、vmstat出力の最初の列です（r）。ここでゼロ以外の値は、より多くのCPUを使用できる場合、システムがより高速に実行されることを意味します。
vmstat最初のデータ行は、最後のブート以降の平均を示しています。 vmstatを起動する前に、平均してスレッドがマシンで待機していました。この値は、週末や他の非稼働時間などの長い非アクティブ期間によってバイアスされているため、一般的に意味がありません。
r b w swap free re mf pi po fr de sr rm s0 s2-in sy cs us sy id３ 0 0 8747008 5562704 865 1866 188 63 63 0 0 -0 9 40 0 762 8588 1495 26 8 66 ↑
他のすべてのサンプルは、空の実行キューを示していますが、最後の2つ目は102スレッドの平均数を示しています。
102 1 0 7717952 4979088 0 1 0 0 0 0 0 0 112 4 0 900 3464 7683 15 9 76↑↑
それでも、CPUは76％この10秒間のサンプル中はアイドル状態です。
明らかな不一致を理解するには、このサンプルの102がaverageの値であることを理解する必要があります。これを取得する1つの方法は、実行キューが1秒間に1020スレッドを保持し、残りの9秒間は空であると想定することです。その102の数値につながる他の組み合わせも考えられます。たとえば、5秒間で204スレッド、他の5スレッドではなしなどです。
ただし、vmstatの最後の列から、この期間中、システムが76％アイドルであったことがわかります。平均実行キューとアイドル状態のCPUに対応するもっともらしい値は408競合中のスレッド2.4秒（100％ビジーなCPU）であり、アクティブなスレッドはない7.6秒先行（CPU使用率0％）。
これで、明らかにCPUの競合が発生したことがわかりました。 2の代わりに408 CPUが利用可能であり、すべてのスレッドが並列でフルスピードで実行できると仮定すると、これらの2.5秒前後6 ms。これは対話型アプリケーションに劇的な影響を与えたでしょうが、残りの時間はとにかく余分なCPUの恩恵を受けないので、バッチジョブにはそれほど影響しませんでした。
結論：
アプリケーションがインタラクティブである場合、システムは深刻に過負荷になり、そうでない場合は、わずかに過負荷になってから「通常の」状態になります。
考慮すべきトレードオフがあります6ミリ秒は、応答時間と408 CPUが高すぎるために「良すぎる」可能性があります。 60ミリ秒がより合理的な目標であると仮定すると、約40 CPで十分に機能し、もちろん2.5 sで問題がなければ、システムは正常に動作しています。正しく。
一般に、ベストプラクティスは、全体の平均実行キューサイズがCPUの数を超えたときに競合があると想定することです。ここでは、37対2です。問題であるかどうかを判断するには、アプリケーションとスレッドを分析する必要があります。影響を受け、それがプラットフォームの運用にどのように影響するか。