1

面白いシナリオがあります。アプリケーションの仮想バイトの値は、私が予想するよりも高くなっています。一方、プライベートバイトは妥当な値です。

これはJavaベースのアプリケーションであり、JNIを介して.Netコンポーネントを同じプロセスにロードします。これは、xmxパラメーターを介して仮想バイトを制限するため、仮想バイトを使用するJavaヒープではありません。

Windbgを使用してVirutalBytesの消費量を分析する方法はありますか?たとえば、コードが別のプロセスとの共有メモリを開く場合、それを確認できますか?これらすべての共有メモリセグメントを合計できますか?

これは本番環境なので、多少制限があります

ありがとうサール

4

2 に答える 2

1

ユーザーモードのデバッグセッションでは、!addressコマンド!address -f:FileMapまたは!address -summary

0:018> !address -summary


Failed to map Heaps (error 80004005)

--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
Free                                    211      7ff`f38e3000 (   8.000 Tb)          100.00%
Image                                   577        0`05cec000 (  92.922 Mb)  46.68%    0.00%
MemoryMappedFile                         60        0`0375a000 (  55.352 Mb)  27.81%    0.00%
<unclassified>                          115        0`0289e000 (  40.617 Mb)  20.41%    0.00%
Stack                                    60        0`00a00000 (  10.000 Mb)   5.02%    0.00%
TEB                                      20        0`00028000 ( 160.000 kb)   0.08%    0.00%
PEB                                       1        0`00001000 (   4.000 kb)   0.00%    0.00%

--- Type Summary (for busy) ------ RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_IMAGE                               578        0`05ced000 (  92.926 Mb)  46.68%    0.00%
MEM_MAPPED                               60        0`0375a000 (  55.352 Mb)  27.81%    0.00%
MEM_PRIVATE                             195        0`032c6000 (  50.773 Mb)  25.51%    0.00%

--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_FREE                                211      7ff`f38e3000 (   8.000 Tb)          100.00%
MEM_COMMIT                              782        0`08ae4000 ( 138.891 Mb)  69.78%    0.00%
MEM_RESERVE                              51        0`03c29000 (  60.160 Mb)  30.22%    0.00%

--- Protect Summary (for commit) - RgnCount ----------- Total Size -------- %ofBusy %ofTotal
PAGE_READONLY                           336        0`050ca000 (  80.789 Mb)  40.59%    0.00%
PAGE_EXECUTE_READ                       104        0`02785000 (  39.520 Mb)  19.85%    0.00%
PAGE_READWRITE                          262        0`010db000 (  16.855 Mb)   8.47%    0.00%
PAGE_WRITECOPY                           59        0`0017d000 (   1.488 Mb)   0.75%    0.00%
PAGE_READWRITE|PAGE_GUARD                20        0`0003c000 ( 240.000 kb)   0.12%    0.00%
PAGE_EXECUTE_READWRITE                    1        0`00001000 (   4.000 kb)   0.00%    0.00%

--- Largest Region by Usage ----------- Base Address -------- Region Size ----------
Free                                      0`ff8b5000      7fd`ed39b000 (   7.992 Tb)
Image                                   7fe`fe39a000        0`0089e000 (   8.617 Mb)
MemoryMappedFile                          0`007b1000        0`012df000 (  18.871 Mb)
<unclassified>                            0`7f0e0000        0`00f00000 (  15.000 Mb)
Stack                                     0`06740000        0`00079000 ( 484.000 kb)
TEB                                     7ff`fff94000        0`00002000 (   8.000 kb)
PEB                                     7ff`fffd9000        0`00001000 (   4.000 kb)
于 2012-12-18T12:58:48.803 に答える
1

仮想バイトは、プロセスが仮想アドレス空間を使用することを表しており、必ずしもメモリ使用量を表すとは限りません。仮想メモリ使用量でさえありません。プロセスが 32 ビットの場合、この統計がギガバイト以上の最良の部分でない限り、心配する必要はありません。

これについては、 Mark Russinovich のブログ エントリPushing the Limiting of Windows: Virtual Memoryで詳しく説明しています。

おそらく代わりに確認したい統計は、Page File Bytes です。Private Bytes と Working Set も興味深いかもしれません。これらは、 Windows Server 2003 Performance Counters Referenceの Technet ドキュメントのProcess Objectで説明されています。

于 2012-12-17T22:32:52.577 に答える