web-dev-qa-db-ja.com

VM上のtaskmgr.exeプロセスの高いCPU負荷の考えられる理由は?

深刻なパフォーマンスの問題があるVMware仮想マシンでは、TASKMGR.EXE(タスクマネージャー)プロセスのCPU負荷が平均20%以上一定であることがわかります。このサーバーで実行されているアプリの負荷は低く、平均で約4〜10パーセントです。 VMは3.75GBのRAMが割り当てられたWindows2003 ServerStandardを実行しています。タスクマネージャーのCPU負荷は他のVMインスタンスと関係があると思われます。 VMWareサーバーですが、内部ESXiシステムで同様の値を確認できませんでした(問題のあるVMはお客様のITで実行されます)。

1
mjn

VMではなくWin7ラップトップ。Taskmgr.exeおよびその他のプロセス(Winmerge.exeなど)がCPUの13%(8つのうち1つ)を使用していた)でも同様の症状がありました。問題再起動により一時的に軽減されたので、たくさんやってました。

長い間調査した結果、Webroot Secure Anywere(ウイルスおよびその他の種類の保護用ソフトウェア)WRSA.exeが原因であることがわかりました。そのプロセスを終了すると、すべてが魔法のように再び速くなり始めました!保護のためにWebrootの代わりに何を使用するかはまだわかりません。

2
Florin D

仮想化サーバーのパフォーマンスは、最初に物理サーバーで評価し、次にVMで評価する必要があります。

VMの内部では、特にVCPUをオーバーコミットした場合、時間の計算は正確ではありません。

また、システム時間に費やされるCPU時間は、パフォーマンスに非常に悪い影響を与える可能性があります。 CPUの合計使用率が15%未満の場合でも、10%でもa VM)の応答時間を2倍にすることができます。

メモリをオーバーコミットしておらず、ホストサーバーがスワップしていないかどうかを確認してください。これにより、パフォーマンスが低下します。 VMwareツールがインストールされ、準仮想化(ダイレクトI/O、バルーン)ドライバーが実行されていることを確認します。

1

タスクマネージャは、リアルタイムで物事を実行しようとします。設定された頻度でリソースをポーリングしています。タスクマネージャーによって監視されているメトリックと負荷の特定のセットについて、命令の数は、動作中のアルゴリズムによって一定の値で決定されます。

特定のメトリックセットに20%のCPUを使用している場合、最初にCPUが多くないためです。 CPUの10倍のマシンで同じ負荷を実行すると、CPUの2%しかかかりません。

したがって、使用されるCPUの割合は、使用可能なCPUを基準にしています。 VMの場合、それは実行されているCPUの物理容量に相対的ですマイナス他のVMによって消費されるCPUの容量。

20%は、VM実行中のCPUの合計に対して多くであり、そのCPUとより良い関係がある場合にのみ重要です。

ところで-CPUが消費されて何か有用なことをしていない場合や、やるべきことがたくさんあるために十分に行っていない場合を除いて、CPUが消費されていることを心配する必要はありません。

100%のCPU消費は悪くありません、それは望ましいです。これは、特定のワークロードに対して、可能な限り高速に実行していることを意味します。 CPUキューを監視します。これが0より大きい場合は、より多くのCPUが必要です。

特に作業を実行しようとしている場合は、100%未満のCPUを使用することは適切ではありません。 CPUは一時的なリソースであることに注意してください。未使用のサイクルは保存できず、価値がありません。それらは単に物事を成し遂げるための無駄な機会を表しています。

最適なシステムは、ロードされていない場合にのみスペアCPUを表示します。

0
cmdematos

2003標準VM vSphere5.1で同様の問題が発生しました。最初は非常に単純なVM(4GB vRAM、20GB vDisk)を2コアの1ソケット。アイドル状態では、プログラムがインストールされておらず、完全に最新であったとしても、VM CPUは常に30〜50%の範囲でした。

さまざまなCPU構成を試しましたが、vCoreの数を1ソケットと2コアから1ソケットと4コアに変更すると(そして再起動すると)、すべてが落ち着き、99%でアイドリングしました。

説明を提供するのに十分なvCPU方法論についてはわかりませんが、おそらくそれは誰かを助けるでしょう

ホスト自体は、2 x16コアAMDを搭載したDL385Gen8です。

0
Tim