質問: リソースモニタとタスクマネージャのram総使用量が、物理メモリの総使用量にリモートで追加されていないのはなぜですか? タスクマネージャやリソースモニタで報告されているramの使用量は、多くの場合、になることがあります。実際の使用量よりも大幅に低くなります。たとえば、私のラップトップやデスクトップで何度も7gbのようなものが使われているのを見たことがありますが、それでもworking ram setの合計は3gbに近いです。どこで使われているのかわからない!これが私がサーバー上のリソースモニターで今日気づいた極端な例です。 フルサイズをクリック 画像を右クリックして新しいタブを開き、数字を表示すると、ワーキングセット(物理的ではない仮想メモリは含まれていません)の合計が約1.7gbになることがわかります。 [すべてのユーザーからのプロセスを表示]が有効になっている場合、タスクマネージャでramの使用量を合計しても、同じような数字になります。これがタスクマネージャの[パフォーマンス]タブのスクリーンショットです。 フルサイズをクリック これは7.6gbの物理メモリが使用中であることを示しています。私はこれをずっと見ています、パーソナルコンピュータ、ラップトップ、そして今やサーバー:システムツールによって報告されたram使用量の合計は私が観察したram使用量の約1/4に過ぎません。wtfが進行中です???私のramがすべてどこにあるのかについて、満足のいく説明はありますか。何が原因なのでしょうか。そして何故痕跡を残さないのでしょうか。編集:ユーザーwhsが要求したように、グラフィカルなramの使用法の写真です。 フルサイズをクリック 編集2:jamesの回答に応えて、サイズ別にソートされたpoolmon.exe内のページングされていないプロセスの図です。これらの結果は私を混乱させる。 poolmonは、使用中の6gbの非ページプールがあることを正しく示していますが、すべての非ページプールプロセスのサイズは8mb未満です。これはどういう意味ですか? poolmonは、非ページプールを使用しているプロセスの一部を検出できませんか?
回答: すみません、私はこれが軽快な反応のように聞こえるのを知っています...しかし、あなたのタイトルの質問に対する答えは「彼らがそうであるはずがないので」です。あるいは、より丁寧に言うと、プロセスのプライベートワーキングセットにはない、ramの使用法がたくさんあります。そのうちのいくつかはプロセスの共有ワーキングセットにあります - しかし、あなたはそこに実際の使用法の信頼できる概念を共有するために得ることができません。プロセスの数を合計すると、あまりにも大きな結果になります。非ページプール、ページプールの常駐部分、その他のカーネルスペース使用の常駐部分など、ramを占有するその他の要素は、タスクマネージャの「プロセス」表示にはまったく表示されません。あなたの特定の問題に関して:タスクマネージャ画面で、「カーネルメモリ」セクションを参照してください。 6 gbの「非ページメモリ」(非ページプール)があります。これは、2番目のグラフの「使用中」セクションの一部です。非ページプールはどのプロセスにも課金されません。そのため、タスクマネージャでプロセスごとの数を合計しても、使用中の合計数に近づくことはありません。一部のドライバはおそらくそれを使用しています。これは全く過剰な量です。 1 gbを大きく下回るはずです。ページングされていないプールの使用量の過度の部分をどのドライバが担当しているかにかかわらず、疑いの余地なくバグがあります。rammapはこれを確認することができます(その「use counts」タブで、「nonpaged pool」の合計を調べます)が、どのドライバーが原因であるかを見つけるのに役立ちません。これを見つける方法は次のとおりです。マイクロソフトのツール「poolmon」のコピーを入手します。これは、windows driver kitと共に配布されている文字モードのツールです(男の子、これまでにありました)。 windows 7の場合、wdkは 無料ダウンロードです 。あなたは全部をダウンロードし(それはisoです)それからそれをインストールしなければなりません、しかしあなたが望むならそれだけでツールだけをインストールすることを選ぶことができます。wdkディレクトリでpoolmonを探します - 必ず32ビットまたは64ビットの正しいものを選択し、管理者のコマンドプロンプトから実行してください。次のような表示が得られます。さて、 "type"欄に "nonp"だけが表示されるまで "p"キーを押します(いいえ、冗談ではありません。メニューはありません!)次に「b」を押して(必要な場合は2回)、「bytes」列の降順に表示をソートします(これは、このサンプルでは既に行われています)。それから一番上の行の "tag"列を見てください。ここに示されている(明らかに人工的な)ケースでは、それは "リーク"です。 (このシステムは、この問題を引き起こすために故意にバグを持っていたドライバを実行しています - それは「非リークの」非ページプールです。)ところで、強調表示されている行は、この古風な画面への前回の更新以降に変更された行です。その文字列を含む.sysファイルのc:\ windows\system32\driversを検索します。この場合、次のように "leak"を探します。c:\windows\system32> findstr /s leak *.sys それからウェブでその文字列やそのドライバ名への参照を探します。ここに戻って.sysファイルからフルネーム、製造元名などを報告することも役に立ちます。(私が思うに、見つけたタグはecmcで、ドライバはintmsd.sysで、expresscacheまたはintellimemoryという製品に関連付けられています。その製品を「アンインストール」します。問題を解決するためのアップデートもあります修正版では、この製品によってシステムのパフォーマンスが向上することは一度もありませんでしたが、本質的には既にwindowsに備わっている機能と重複しています。)それが見つからない場合は、次のステップは「windows performance toolkit」を使うことです。そのフォーラムでこの文字列を検索し、magicandre1981による回答を得て、使い方を見つけましょう。 xperfについて言及している回答は無視してください - これはこのツールの古いバージョンです。更新:コメントによれば、opは上記を行い、poolmonが非ページプールの合計サイズは確かに巨大であると報告していますが、割り当てられた部分はすべて明らかに小さいことがわかりました。私の予想では(これもコメントで)これは私が "肥大化した"プールと呼ぶものによるものであるということです:プールは割り当てられ、その後解放されましたが、プールに割り当てられたram 「解放」を反映するために。 magicandreによる この答え で説明されている手順に従って、犯人を特定することができます。