SVCHOST /ワークステーションサービスでのWindows 2012 Core Extremeメモリの使用


9

約200台のサーバー、Hyper V、ファイルクラスター、IISがあり、すべて同じ問題が発生しています。サーバーでRAMの上限または上限に近い通常の使用によってサーバーでイベントが発生します。これが発生すると、SVCHOST /ワークステーションサービスは、具体的に(ワークステーションサービスをそれ自体のSVCHOSTに分離することで除去された)ハンドル/スレッドの解放を停止し、そのサービスで使用されているメモリは解放されません。極端な場合には、255GBサーバーで40GBのRAMを使用するワークステーションサービスがあります。また、4000万以上のハンドルを見つける場合もあります。

もちろん、再起動すると問題はなくなり、W3プロセスやHyperV VMなどによってすべてのメモリが使用されるまで、問題は解消されます。その後、WorkstationサービスがすべてのRAMの取得を開始します。プロセスは非常に遅く、サーバー上のRAMの量によっては数週間から数か月かかることがあります。

当社のHyper VサーバーとIISサーバーはどちらも作業ファイルの共有にアクセスします。これらの共有はSSDストレージ上にあるため、十分なパフォーマンスを発揮します。現在のすべてのパッチをインストールしましたが、これを重要なステップにして、R2で修正されるという明確な兆候を見つけることができない多くのツールがあるため、R2には移動していません。

私たちはProcMonと他のツールを実行しましたが、最も問題のあるサーバーではこれらのツールは実行されません。他のものについては、それらが提供する結果は、そのプロセスで実際にメモリリークがあるように見えることを示しています。

このプロセスからメモリを解放したり、一緒にバグを回避したりする方法はありますか?再起動する必要はなく、エラー状態になるとプロセスを再起動できません。プロセスがフリーズします。

私たちはこの問題を「修正」するために定期的な再起動を行わないように努めていますので、どんな答えもありがたいです。


あなたの質問は何ですか?
Andrew Schulman

確かにそうですが、スレッドが数千/数百万開いているだけで、あいまいです。最も問題のあるシステムでは、これらのツールを実行することさえできません。サーバーをクラッシュさせるだけです。
Craig

ボックスを再起動する以外の問題を解決するための良い解決策を見つけたいと思います。この問題が発生すると、サービスを停止できなくなります。
Craig

KB 2811660がインストールされていますか?これらのシステムはサーバーマネージャーを実行していますか?support.microsoft.com/kb/2793908

はい、このKBは少し前にインストールされました。また、このリークはワークステーションサービスに固有のものであり、そのKBはWMIサービスに適用されます。
Craig

回答:


1

svchostがサーバーのパフォーマンスを破壊しているという不気味な同様の問題がありました。

解決策:完全なイベントログがあったことがわかりました。私はそれを片付けました、そして、すべてが今まで何も起こらなかったようにバックアップして実行していた。

(イベントログのサイズをデフォルトから変更することもお勧めします。以下を参照してください)

Windowsインターフェイスを使用して最大ログサイズを設定するには
-イベントビューアを起動します
-コンソールツリーで、管理するイベントログに移動して選択します。
-[操作]メニューの[プロパティ]をクリックします。
-[最大ログサイズ(KB)]で、スピナーコントロールを使用して必要な値を設定し、[OK]をクリックします。

ここで起こっていることとまったく同じように聞こえますが、最終的には非常に簡単な修正になりました。再起動すると一時的に問題が解決しますが、何かがログへの書き込みを試みるとすぐに、すべてが手に負えなくなり、リソースを使い果たし続けます。

お役に立てれば!


-1
>Is there a way we can free up the memory from this process ?

外部から(適切に)割り当てられたメモリを解放したり、問題のアプリを強制終了せずにリソースを処理したりする方法はありません。

>or avoid the bug all together? 

メモリとリソースのリークが発生しています。問題を解決する唯一の方法は、リークを見つけ、そのトリガーを回避する(可能な場合)か、ソースコードレベルでリークを修正することです。最後のケースでは、パッチを作成するためにMicrosoftのヘルプが必要ですが、問題が実際にどこにあるかを「正確に」伝えるように期待されているようです。

MS Application Verifierを使用してメモリ/リソースリークを特定することにより、原因を特定することができます。


トリガーはファイル共有ですが、これは避けられません。
Craig

トリガーを回避できない場合は、「Application Verifier」でリークを見つけ、その情報をMSに連絡してください。
Pat

アプリケーションは複数あるため、すべてMicrosoftです。既に連絡済みですが、これを整理するのに数週間から数か月かかる可能性があるとのことで、より迅速な解決策を探しています。
Craig

MSが現在のOS以外でこの種の問題を解決するために急いでいないことを考えると、より迅速な解決策が見つかるとは思いません。別のことは、リークがどこにあるかを彼らに伝える場合です。
Pat

未解決のケースがあり、1か月間彼らと協力してきました。リークは文字通りWorkstationサービスにあります。
Craig

-1

RAMの作成は簡単ですが、解決策はありません。

詳細な調査には、Sysinternals RAMMAPまたはVMMAPをお勧めします。このツールを使用すると、何が起こるかをよりよく確認できます。多くの場合、これはメタファイルの問題です。

Server 2008以降、この問題はすべてのターミナルサーバーでメモリ不足になり、アプリケーションを共有から起動すると、時間の経過とともに信じられないほどのメモリ消費が発生します。

私たちの回避策は、別のターミナルサーバーでそのアプリケーションをホストし、メモリ消費を頻繁にクリアすることです。

これは、
すべてのプロセスでSeDebugPrivilegeを指定したSetProcessWorkingSetSize()を使用して、自己設計のc ++コマンドラインアプリケーションで行います。

このようなことをしないことを強くお勧めします;)


なぜ反対票を投じるのですか?要求された正確なもの!ここで助けようとすることは喜びではありません...
Magnus
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.