Hyper V、ファイルクラスター、IISの約200台のサーバーで同じ問題が発生しています。通常の使用でサーバー上でイベントが発生し、最大またはほぼ最大になりますRAMこれが発生すると、SVCHOST/Workstationサービス、具体的には(Workstationサービスを独自のSVCHOSTに分離することで排除されます)、ハンドル/スレッドの解放が停止し、そのサービスで使用されているメモリが解放されることはありません。場合によっては、255GBサーバーで最大40GBのRAMを使用しているワークステーションサービス。場合によっては、4,000万を超えるハンドルが検出されます。
もちろん、再起動すると問題は解消され、W3プロセスやHyperV VMなどによってすべてのメモリが使用されるまで再び表示されません。その後、ワークステーションサービスがすべてのRAMの取得を開始します。このプロセスは非常に遅く、サーバー上のRAMの量によっては、数週間/数か月かかる場合があります。
HyperVサーバーとIISサーバーの両方が作業ファイルの共有にアクセスします。これらの共有はSSDストレージ上にあるため、十分なパフォーマンスがあります。現在のパッチをすべてインストールしましたが、R2には移行していません。これを重要なステップにする多くのツールが用意されており、これがR2で修正されるという明確な兆候を見つけることができないためです。
ProcMonやその他のツールを実行しましたが、最も問題のあるサーバーでは、これらのツールは実行されません。その他の場合、それらが提供する結果は、そのプロセスで実際にメモリリークが発生しているように見えることを示しています。
このプロセスからメモリを解放したり、バグをまとめて回避したりする方法はありますか?再起動する必要はなく、エラー状態になるとプロセスを再起動できません。プロセスがフリーズします。
この問題を「修正」するために定期的な再起動を行わないようにしていますので、ご回答いただければ幸いです。
Svchostがサーバーのパフォーマンスを破壊していたという不気味な同様の問題がありました。
解決策:完全なイベントログがありました。私はそれを片付けました、そして何も起こらなかったようにすべてがバックアップされて実行されました。
(イベントログのサイズをデフォルトから変更することもお勧めします。以下を参照してください)
Windowsインターフェイスを使用して最大ログサイズを設定するには
-イベントビューアを起動します。
-コンソールツリーで、管理するイベントログに移動して選択します。
-[アクション]メニューで、[プロパティ]をクリックします。
-[最大ログサイズ(KB)]で、スピナーコントロールを使用して必要な値を設定し、[OK]をクリックします。
ここで起こっていることとまったく同じように聞こえますが、最終的には本当に簡単な修正になりました。再起動すると一時的に問題が解決しますが、ログに書き込もうとするとすぐに、すべてが手に負えなくなり、リソースを使い果たしてしまいます。
お役に立てれば!