弊社には、Hyper V、ファイル クラスター、IIS など、約 200 台のサーバーがあり、すべて同じ問題が発生しています。通常の使用中にサーバー上でイベントが発生し、サーバーの RAM が最大またはほぼ最大になります。この問題が発生すると、具体的には SVCHOST/Workstation サービス (Workstation サービスを独自の SVCHOST に分離することで除去) がハンドル/スレッドの解放を停止し、そのサービスが使用するメモリが解放されなくなります。極端なケースでは、255 GB のサーバーで 40 GB もの RAM を使用する Workstation サービスがあります。場合によっては、4,000 万以上のハンドルが見つかることもあります。
再起動すると、もちろん問題は解消され、W3 プロセスまたは HyperV VM などによってすべてのメモリが使用されるまで再び発生しません。その後、Workstation サービスがすべての RAM を取得し始めます。このプロセスは非常に遅く、サーバーの RAM の量に応じて数週間から数か月かかる場合があります。
当社の Hyper V サーバーと IIS サーバーは両方とも作業ファイルの共有にアクセスします。これらの共有は SSD ストレージ上にあるため、十分なパフォーマンスを発揮します。現在のパッチはすべてインストールしましたが、R2 に移行していません。これは、これを重要なステップにするツールが多数導入されており、R2 でこれが修正されるという明確な兆候が見つからないためです。
ProcMon やその他のツールを実行しましたが、最も問題のあるサーバーではこれらのツールは実行されません。その他のサーバーでは、提供される結果には、そのプロセスで実際にメモリ リークが発生しているように見えることだけが表示されます。
このプロセスからメモリを解放したり、バグを完全に回避したりする方法はありますか? 再起動は避けたいのですが、エラー状態になるとプロセスを再起動できません。プロセスがフリーズしてしまいます。
この問題を「修正」するために定期的に再起動することを避けようとしているので、ご回答いただければ幸いです。
答え1
svchost がサーバーのパフォーマンスを低下させるという、不気味なほど似た問題が発生しました。
ソリューション：結局、イベント ログがいっぱいになっていました。それをクリアすると、何も起こらなかったかのようにすべてが元に戻り、実行されました。
(イベント ログのサイズをデフォルトから変更することもお勧めします。以下を参照してください)
Windowsインターフェースを使用して最大ログサイズを設定するには
- イベント ビューアーを起動します。
- コンソール ツリーで、管理するイベント ログに移動して選択します。
- [操作] メニューで、[プロパティ] をクリックします。
- [最大ログ サイズ (KB)] で、スピナー コントロールを使用して必要な値を設定し、[OK] をクリックします。
ここで起こっていることとまったく同じですが、結局は簡単に解決できました。再起動すると一時的に問題は解決しますが、ログに何かを書き込もうとすると、すべてが手に負えなくなり、リソースを消費し続けます。
お役に立てれば！
答え2
>Is there a way we can free up the memory from this process ?
問題のあるアプリを終了せずに、割り当てられたメモリを外部から（適切に）解放したり、リソースを処理したりする方法はありません。
>or avoid the bug all together?
メモリとリソースのリークが発生しています。この問題を解決する唯一の方法は、リークを見つけて、そのトリガーを回避するか (可能な場合)、ソース コード レベルでリークを修正することです。最後のケースでは、パッチの作成に Microsoft の支援が必要ですが、Microsoft は、問題が実際にどこにあるのかを「正確に」伝えることを期待しているようです。
例えばMSを使ってメモリ/リソースリークを特定することで、犯人を見つけることができます。アプリケーション検証
答え3
RAM をクリアするのは簡単ですが、解決策はありません。
より詳細な調査には、Sysinternals RAMMAP または VMMAP をお勧めします。このツールを使用すると、何が起こっているかをよりよく確認できます。多くの場合、これはメタファイルの問題です。
Server 2008 以降、共有からアプリケーションを起動すると、時間の経過とともに信じられないほどのメモリ消費により、すべてのターミナル サーバーでメモリが不足するという問題が発生しています。
回避策としては、そのアプリケーションを別のターミナル サーバーでホストし、メモリ消費を頻繁にクリアします。
これを、すべてのプロセスでSeDebugPrivilegeを使用してSetProcessWorkingSetSize()を使用する独自設計のC++コマンドラインアプリケーションで実行します。
このようなことを行わないことを強くお勧めします ;)