メモリが解放されない？

鈴菜萌さん、情報提供ありがとうございます。

タスクマネージャのコミットサイズはこちらでも確認しています。

が、数値的には大した大きさではなく、何GBも消費しているようには見えなかったので、「タスクマネージャの数値は当てにならない」か「タスクマネージャで表示される以外のコミットメモリが増えている」と考えていました。

もしよろしければ、rammapというユーティリティを試してもらえませんか？

これはsysinternalsのツールの一つなので怪しいものではないようです。

私が気づいたことの一つに、「コミット済みメモリを消費（浪費？）しているプロセスは、’Page Table’のサイズが大きくなっている傾向がある」ということがあります。

rammapを起動して[Processes]タブを開くと、'Page Table'という列があります。私のPC（Windows8.1)では、コミット済みメモリが増えてきた時にこの'Page Table'を降順に並べ替えると、必ずと言っていいほどexplorer.exeとtaskhostex.exeが上位に来ています。他のプロセスと較べても、飛び抜けて大きい数値を示しています（といっても、4000～8000K程度ですが）。

このとき、そのプロセスを強制的に殺すと、コミット済みメモリが劇的に下がります。ただし、taskhostex.exeをkillするとシステムの動作に大きな影響があるので、リブートせざるを得なくなりますのでご注意下さい。

参考までのスクリーンショットを添付します。まずは、explorer.exeを殺す前です。

次に、explorer.exeを殺した後です。

この’Page Table’列で表示されている数値の具体的な意味はわからないのですが、少なくともOS起動後はexplorer.exeもtaskhostex.exeもこのPage Tableはそんなに大きな数値ではないです。使い込んでくるうちに、コミット済みメモリが上がるのと同期して増えているのは間違いないです。

また、Page Tableという名前から考えて、仮想メモリの割り当てに関係する数値であることも間違いないでしょう。推測するに、OSがあるプロセスに対して仮想メモリ領域（＝コミット済みメモリ）として与えるけれど、そのプロセス自体はそのメモリを使用していない、つまりプロセス自体のワーキングセットが大きくなるわけではない、と考えています。言い換えると、「OSは、プロセスが必要としないメモリ領域を無駄に割り当てている」という感じでしょうか。

もしこの推測が正しいのであれば、何らかのプロセスが単純なメモリリークを起こしているのではなく（＝ワーキングセットが大きくならない点からもそうだと思われる）、OS自体に何らかの問題があると考えるのがもっともらしいと考えられないでしょうか。実際、このコミット済みメモリを増やしているプロセスは特定のプロセスだけに起こるのではなく、少なくともexplorer.exeとtaskhostex.exeの２つは大量にコミット済みを増やしていますし、おそらくはその他のプロセスも少量ながらそういう現象を起こしているのだと思います。だからこそ、すべてのプロセス分を合算することで、タスクマネージャの「メモリ使用量」＜＜「コミット済み」とその差が大きく解離するのだと考えています。

長文ですみません。

ここはマイクロソフトのサポートサイトではないので、マイクロソフトには伝わらないのでしょうが、かと言って個人的に直接報告したところで、「PC固有の問題」とか「環境のせい」とかで無視されるのがオチでしょう。しかし、少なくともこのコミュニティサイトで私を含め３人の方が同様の症状を訴えておりますし、また私が使用する３台のPCで同じ症状がありますから、やはり固有の問題ではないと思います。同様の症状の人の声を集めて、マイクロソフトに対して何らかの働きかけの一助になればと思い、いろいろと情報を書いています。

返信ありがとうございます。

少し忙しくて間が開いてしまいました。

rammapで試してみましたので結果を貼り付けます。

結論から言うと、表示される値から有意義な情報は得られませんでした。

まずこれがWindows再起動直後です。

数日Flashbuilderで開発、Webで調べ物等々を行い、ここまで増えました。

explorerを再起動しました。

コミット済みが大きく減っているのですが、リソースモニタのコミット値は100MBも変わっていません。

rammapのPage Tableに関しては3MBも変わっていません。

メモリ監視ツールでは見えない部分かつ、explorerに関連づいたコミット済みというものが溜まっていく、という現象ですね。

これは今まで出てきた情報と違いがありません。

ただ、私の環境ではexplorerの減り分から鑑みるに、taskhostexのコミット済みの増加量がそこまで多くないように思います。

おそらく増加分の約4GBの内、ウイルスバスターとパスワードマネージャで半分以上を占めているのではないかと推測します。

また、更に推測ですが、物理メモリが足りなくなってスワップが多く発生すると加速度的にコミット済みの値が増えていくように思いました。

ずっとオンメモリでスワップし続けるexplorerがスワップした仮想メモリを開放していない、と考えるのが妥当ではないか、という推論が現実味を増してきたように思います。

その推論を裏付ける情報が取れないのでなんとも言えませんが・・・。

更に調べてみたいと思います。

それから、ここはマイクロソフトのサポートではありませんが、マイクロソフトのドメインでホストされているコミュニティですので、マイクロソフトが何らかの調査を行ってくれたら嬉しいなぁ、と思う次第です。

また何かありましたらご報告させていただきます。

最近のWindows　Updateを見ていて、関連しそうなfixを見つけました。

http://support.microsoft.com/kb/2935389/ja

機械翻訳は要領を得ていませんが、非ページドプールのメモリリークを発生させるという点と、問題のモジュールがWinsock2関係のドライバであることから、今回の現象と関連している可能性が考えられます（傾向として、WEBブラウザを多用しているとコミット済みメモリが増えていたので、ネットワーク関係ではないかと疑っていました）。

上のページを読むとWindows Serverだけに影響があるようなことを書いていますが、このfixをインストールするために更新プログラム 2955164 をインストールしてみると、問題のafd.sysのバージョンが6.3.9600.16384から6.3.9600.17088にアップデートされましたので、何らかの変化は期待できます。

とはいえ、explorer.exeやtaskhostex.exeをkillするとメモリが解放されるという事実との因果関係を説明できない状況ではありますが、これで現象が解決するかどうかしばらく使ってみて、後日結果を報告したいと思います。

結論としては、先のfix（http://support.microsoft.com/kb/2935389/ja）とは関係がありませんでした。

このfixを適用していても、やはりコミット済みメモリは増えていきます。

使用頻度の高い２台のPCで再現しました。

再三、書いていますが、explorer.exeかtaskhostex.exeを強制的に終了させると、コミット済みメモリが解放されることは間違いないです。そして、rammapツールで確認できるPageTable使用量との因果関係が疑われますが、今回はこれをグラフにしてみました。

X軸は、強制終了させる時点でのPageTableの使用量（KByte）で、Y軸はそのプロセスを終了させることによって増加した（解放された）コミット済みメモリ（GByte）です。

明らかに線形的な因果関係が認められます。しかし、原因については謎のままです。

VirtualAllocや、ファイルマッピングなどのAPIを使ったテストプログラムを書いて再現を試みたのですが、プロセス毎のメモリ使用量（ワーキングセットサイズ）を上昇させずに、コミット済みのみを増加させるようなことはできませんでした。

質問者です。

もうこのスレッドにコメントが付くこともなくなり、私自身ももう諦め半分ですが、同じような症状に悩まされている人のためや、（可能性は小さいが）Microsoftのエンジニアがこれを読んで「よし、調べてやろう！」と思ってくれることを期待しつつ、新しい情報を書き込みます。

新しいPCを買ったのですが、やはり同じ症状が出ます。タスクマネージャ上で、「使用中」と「コミット済み」の量に大きな乖離が見られ、メモリの一部が開放されていないようです。explorerやtaskhostexを強制終了すると、コミット済みが大幅に減る点も同じです。

これまでは、どうもブラウザ、特にChromeをインストールしている影響があるような気がしていたので、この新しいPCでは敢えてChromeを入れずに標準のIEだけで使ってきましたが、問題は出ます。Chromeはシロだったということになります。

休止状態を使わず、再起動をすればよいだけのことなので、****り誰も気にかけないのでしょうね。

ちなみに、新しいPCはWindows 8.1 Update(64bit)です。