vmstat
こんにちは。一部のテスト中に機械のパフォーマンスを追跡するために.を使用していますjmeter
。これは、他の多くの仮想マシン(約20台の仮想マシン)がインストールされている大規模マシンで実行されている仮想マシンです。
次のソフトウェアバージョンを使用しています。
$ vmstat -V
procps version 3.2.7
$ uname -a
Linux cmbpm 2.6.32-042stab044.11 #1 SMP Wed Dec 14 16:02:00 MSK 2011 x86_64 x86_64 x86_64 GNU/Linux
問題は私が得た結果です。例は次のとおりです(より簡単なデータ処理のためにスペースを単一のタブに変換しました)。
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 1506720 6152768 0 824836 1 0 3 2 0 0 0 0 94 6 0
0 0 1506720 6170744 0 804392 60 64 14 16 0 122651 0 0 98 2 0
0 1 1506720 6168328 0 801744 145 8 300 52 0 117308 0 0 0 100 0
0 0 1505688 6173360 0 806852 233 13 1135 478 0 109158 1 0 387 1171860851 0
0 0 1505172 6168988 0 810140 380 0 0 513 0 117875 0 0 97 3 0
問題は、いくつかの値が元のものよりはるかに大きいということです。 CPU時間のパーセント値(-----cpu------
小数)が100%を大幅に超えることがあります。特に列wa
(Waiting for data)が問題になります(値1171860851が非常に奇妙です)。これらの巨大な値をゼロに変更すると、合理的な結果が得られます。
私の質問はなぜ間違った値を提供し、何とか修正することができますか?
ここではマシン仮想化が問題のようです。
答え1
一般的な容疑者は次のとおりです。
vmstat
カウンターラッピングは処理されない可能性があり、カウンターは頻繁にラップされてはならず、iowait(通常のロードの場合)よりもユーザー/システム/アイドル状態で発生する必要があります。vmstat
解析できません/proc/stat
。これは、64ビットデータ型が原因で直接的または間接的に発生する可能性があります。または、広いフィールド/欠落/マージされたフィールドによるオーバーフローまたは解析エラーのためです。- 時間歪みにより計算が歪む
カーネルはuser / nice / system / etcをカウンタ(通常100 / CPU)として追跡しますvmstat
が、他のプログラムは時間増分(5秒など)に基づいて平均を計算しますvmstat 5
。説明されている特定の症状はありませんが、正確なタイミングは仮想環境で問題になる可能性があります(vmstat
同じタイムスタンプを使用してこの数を計算します)。
/proc/stat
procps/libproc を確認した後、長い整数で読み込み、計算に倍精度浮動小数点を使用します。何の問題も見られません。
OpenVZカーネルを実行しています。/proc/stats
形式が正しいことを確認する必要があります。おそらく、次のエラーが発生する可能性があります。https://bugzilla.openvz.org/show_bug.cgi?id=1376
解析を行うと、より良い運が得られます/proc/vz/vestat
。http://wiki.openvz.org/Vestat