実行中のプロセスのリスト外のWindows Serverでのメモリ使用量を説明する方法

Windows 2003 Serverの実行速度が少し遅いため、最終的に再起動するまで、コミットチャージとページファイルの使用量が増え続けています。これを修正するには、すべてのメモリを消費しているものを見つける必要があります。これが大きな謎です。

タスクマネージャからの現在の統計：

Physical Memory (K): 2096400
Commit Charge (K):   5364848
Page file usage:     5.11 GB

では、SysInternals Process Explorerをプルアップして、実行中のすべてのワーキングセットサイズを確認しましょう。最大の原因は、121,980K WS、481,284K VMサイズを使用するTomcatインスタンスです。5 GBのコミットチャージを説明することはできません。

次のステップ：のSysinternals pslistは：pslist -m、報告されている61回の処理のためにカラムと計算カラム合計により出力を分割します。

SUM (Working Set)  : 681,484 K
SUM (Private Bytes): 593,424 K

ツールが報告しているものを根本的に誤解していますか？私は常に、OSが実際にそれほど多くのメモリを使用しないことを前提として、プロセスによってマップされた仮想メモリの全量よりもはるかに少ないメモリをOSが実際にコミットするという印象を受けていました赤いニシン。

JPさん、これは自動化されたビルド/単体テストサーバーであり、安定したコードよりも実行率が低いというコメントを信じています。私の推測では、このサーバーで実行されている不安定なコードはおそらくメモリリークを引き起こしているため、このサーバーを頻繁に再起動する必要があります。メモリリークは、実行中のプロセスのどのプロセスツリーにもリストされません。メモリリークは、存在しないプロセスによって取得され、割り当てられているプロセスですが、それらに関連付けられているプロセスが長く実行されているにもかかわらずです。

頻繁にメンテナンスウィンドウを取得し、この動作がパフォーマンスの問題を示し始める速度に応じて、おそらく毎晩、週に数回、または毎週、このマシンを自動的に再起動できるようにします。

Windozeにはしばらく前からOracle Application Serversサーバーがあり、1日2回再起動する必要がありました。ユーザーを昼食時と毎日真夜中に追い出しました。これは数年前のことで、オラクルの安定した製品コードと思われます。

リンクを貼り付けるだけで申し訳ありません。しかし、ログパーサーとpowershellを使用して、メモリリークを見つけるためにいくつかの手法を使用してきたので、共有します。

http://blogs.msdn.com/debuggingtoolbox/archive/2008/08/22/powershell-script-chart-and-statistics-from-top-20-objects-leaking.aspx

（Never Doubt Thy Debuggerサイトは優れています）：http : //blogs.msdn.com/carloc/archive/2007/09/14/something-you-need-to-know-before-start-debugging.aspx

Mark RussinovichのWindowsでのメモリ使用量に関する優れた洞察へのリンクも提供します。

http://blogs.technet.com/markrussinovich/search.aspx?q=memory&p=1

実際のMicrosoftケースを開く前に、Performance Teamサイトにも多くの良い情報があります：http : //blogs.technet.com/askperf/Default.aspx?p=2

これを診断するのに役立つ原則的なツールは、perfmonです。（最初に）調べたいカウンターは次のとおりです。

メモリ、コミットされたバイトこれは、仮想メモリの需要の測定です
プロセス、ワーキングセット、_アクティブな使用中の仮想メモリの合計
ページングファイル、使用中のページファイル％
メモリ、ページ/秒（これは必ずしもメモリ不足のインジケータではありません） 、だれもがそうだと思っているようですが）
メモリ、ページ出力/秒他の目的で毎秒RAMページフレームを解放するためにページファイルに書き込まれた仮想メモリページの数

メモリ、キャッシュバイト
メモリ、プール非
ページバイト
メモリ、プールページバイトメモリ、システムコード合計バイト
メモリ、システムドライバ合計バイト

この合計が2GBに近づくと、通常32ビットアーキテクチャが原因でパフォーマンスの問題が発生します

メモリ、利用可能なMバイト-これは、仮想メモリ（新しい割り当て、またはページファイルからのページの復元）の要求を満たすために利用可能なRAMの量を測定します。

http://members.shaw.ca/bsanders/WindowsGeneralWeb/RAMVirtualMemoryPageFileEtc.htmも参照してください。

前回の再起動以降、そのサーバーはどのくらいの期間稼働していますか？Windowsにメモリリークがあるのは残念なことです。つまり、割り当てられたメモリは、常にシステムに解放されるとは限りません。症状はまさにあなたが見ているものです。まだ行っていない場合は、少なくとも週に1回は再起動することをお勧めします。サポートコールを大幅に削減できるため、多くのデータセンターではWindowsを毎日再起動しています。もちろん、ダウンタイムがないので、クラスターを使用する方がはるかに簡単です。

Windowsのメモリ統計を本当に理解しているシステム管理者がどこかにいると言われていますが、私はそれらに会ったことがありません。

ただし、通常、動作に問題のあるプロセスを見つけることはそれほど難しくありません。Perfmonを使用して、ハンドルやページフォールト/秒などのさまざまなプロセスカウンターを確認してください。

JR

さらに考えてみましょう：実際にメモリが不足していますか？重要なのは、ページングが発生しているかどうかです。ページングがない場合、メモリが不足しているわけではありません。PerfMonを使用して、Memory-Pages / secカウンターを確認します。

ワーキングセットは、REAL物理メモリによって実際に表されるメモリのビットであることに注意してください。また、仮想メモリ使用量もあり、Windowsはコードページの共有を行います。MFCのいくつかのチャンクは、メモリ使用量を重複させることなく、多数のプロセス間で共有されます。さらに、ファイルシステムキャッシュをできるだけ大きくしたいというWindowsの絶え間ない欲求があります（以前に2.5 GBのラップトップで800 MBに膨らむのを見たことがあります）。

Windowsのメモリ管理は非常に堅牢です。ただし、Windowsがページングを開始すると、状況は醜くなり、常にファイルシステムキャッシュ用の領域を常に残しておく必要があります-常に常に。80以上のタブでメモリの消費量が最大1.2gb / 1.2 + gbになると、Firefoxをシャットダウンして再起動する必要があります。

また、Windowsは、キャッシュにあるページと、メモリ/ワーキングセットとしてリストされているページの間のラインを少しぼかします。