非ページメモリをリークしているアプリケーションを特定するにはどうすればよいですか？

最近、ライブサーバーでWebアプリが応答しなくなる問題が発生しました。私たちが得ていたのは、サーバーを再起動するまでの503エラーだけで、それで問題ありませんでした。最終的には、それをhttperr.logまでたどると、1_Connections_Refusedエラーがたくさん見つかりました。

さらなる調査により、非ページプールの制限に達したことが示されているようです。それ以来、Poolmon.exeを使用して非ページプールメモリを監視しており、問題の原因となっているタグを特定したと考えています。

Tag   Type    Allocs       Frees       Diff       Bytes      Per Alloc
Even  Nonp  51,231,806   50,633,533   684,922   32,878,688      48

poolmon.exe / gを使用すると、マップされたドライバーが[<不明>イベントオブジェクト]として表示されます。

これはほとんど役に立ちません。私のチームはこの問題の調査にかなりの時間を費やしており、これを特定のアプリケーションまたはサービスに絞り込むためのプロセスを見つけることができませんでした。ほとんどの人は、ページングされていないメモリがリセットされるまで、マシン上のプロセスを強制終了することで問題を解決しているようです。これは、実稼働マシンで作業するときに見たいとはまったく言えません。

タスクマネージャを開いてプロセスリストを表示した場合。NPプール値が105KのMailService.exeが表示されます。これは、2番目にリストされているプロセスの値より36K高いです。過去にメールサーバーでいくつかの問題が発生したため（この問題に関連するかどうかに関係なく）、私の直感は、これが問題の原因であると感じています。

ただし、サービスを再開する前に、単なる「直感」よりも少し確信を持ってみたいと思います。

私もpoolmon.exe / cを使用してみましたが、これは常にエラーを返します：

unable to load msvcr70.dll/msvcp70.dll

そしてそれはlocaltag.txtを作成しません。どこにあるのかわからないので、同僚がpooltag.txtをインターネットからダウンロードする必要がありました。winデバッガーやwin DDKがインストールされていません（私が確認できます）。これらのいずれもインストールされていないため、上記のエラーが表示される可能性がありますが、わかりません。

最後に私は試しました：

C:\windows\system32\driver\findstr /m /l Even *.sys

これにより、かなりのサイズの.sysファイルのリストが返され、問題は解決しませんでした。

だから私の質問はこれです：このメモリリークの原因を絞り込む他の方法はありますか？

更新：

以下に提案するように、私は最終日ほどプール非ページバイトをログに記録しており、プロセスが上昇しているかどうかを確認しています。ほとんどの場合、すべてのプロセスは、その使用においてかなり静的であるように見えます。そのうちの2つは、わずかに上昇しているようです。私はこれを今後数日間監視し続けます。

また、プロセスのいずれも過度の数のハンドルを使用していないように見えることも前に言及するのを忘れていました。

更新2：

私はこれをここ数週間監視してきました。個々のプロセスの非ページバイトプールと合計非ページバイトプールは、その間比較的安定しています。この間にWindowsが更新され、サーバーが再起動したので、問題が解決したかどうか疑問に思っています。私はこれに先立っていたので、非ページバイトプールで一貫した成長が確実に見られません。

私はこれを約6〜7週間監視しており、ようやく問題に対する明確な答えを出すことができます。

まず、個々のプロセスの非ページ化バイトは、それらがすべてその使用においてかなり静的であるように見えたため、実際には何も有用なことを教えてくれませんでした。スパイクがありましたが、その後は常にベースラインに戻りました。

Nonpaged Bytes Memoryの合計もしばらくの間は静的でしたが、その後徐々に増加し始めてから急上昇しました。スパイクの後、メモリの約半分が解放され、パターンが繰り返されるまでしばらくの間（より高いレベルで）静的なままでした。グラフを見ると、これらのスパイクはかなり規則的に配置されているように見え、2週間おきに日曜日に発生していることがわかりました。

したがって、次の質問は、隔週で日曜日に何が実行されているかということでした。私はイベントビューアを確認しましたが、スパイクが発生するたびにMcAfeeが実行されていました。また、サーバーに頻繁にログオンして問題を監視すると、マカフィーにはリアルタイムスキャナーが搭載されているため、うっかり問題を悪化させたと考えています。

スケジュールされたタスクであるスキャンは、McAfee固有のタグではなく、PoolMonのイベントオブジェクトタグに添付されたNPメモリの増加を確認した理由も説明していると思います。これが私たちを本当に庭の道へと導いた主なものでした。

リークの原因がわかったので、これに対して何かを行うことができます。それを追跡するのにこれだけ長い時間がかかったのは信じられないことです。

更新：ちょうど最後のメモとして。McAfeeは週末に更新され、これにより非ページメモリの問題が完全に解決されました。

更新2：これについて賛成票を獲得したばかりなので、これに更新を追加します。最初は、McAfeeへのアップデートで問題が解決したように見えました。つまり、NPメモリの大きなスパイクが定期的に見られなくなりました。また、アップデート以降、McAfeeがデフォルトでイベントビューアにログを書き込まなくなり、アクティブにスキャンしている場合は非表示になることにも気付きました。

しかし、NPのメモリ使用量は徐々に増加しています。これで、2週間ごとにサーバーを再起動する必要があります。それは我々が最近更新されたハードウェアとソフトウェアがこの問題を離れて行くようになることを期待して新しいサーバーを取得することをとても残念だしかし唯一のWindows Server 2008での私達の完全に新しいサーバー、SQL Server 2008のR2、およびマカフィーはしてインストールSTILL NPメモリリークを示します。McAfeeを完全に削除した後で初めて、リークが停止し、スイッチオーバーに備えてすべてのソフトウェアをサーバーにセットアップした後でも、リークは静的のままでした。

私はそれ以降読んだのですが、これが真実であるかどうかはわかりませんが、問題はMcAfeeにあるのではなく、McAfeeが使用するNPメモリがリークする原因となるWindowsルーチンにあります。どうやら、ネットワークアクティビティがリークの原因です。つまり、ネットワークアクティビティが増える=>リークが大きくなります。これは、サーバーがビジーになるにつれてリークが悪化するという点で、私たちの経験と一致しているようです。