CODEWITHSUNDEEP
windowswindbgproduction-environment
Saar
Saar

Reputation: 1803

Windbg - analyze Virtual Bytes

I have an interesting scenario. The application has higher value of Virtual Bytes than I would expect. On the other hand, the Private Bytes is at a reasonable value.

This a Java based application which also loads via JNI a .Net component to the same process. This is not the Java heap that takes the Virtual Bytes as I limit it via xmx parameter.

Is there a way I could analyze using Windbg the consumption of the Virutal Bytes? For instance, if the code opens a shared memory with another process - can I see it? Can I sum all those shared memory segments?

This is a production environment so I am somewhat limited

Thanks Saar

Upvotes: 1

Views: 1427

Answers (2)

Serg
Serg

Reputation: 2180

In user-mode debugging session you can use !address command !address -f:FileMap or !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)

Upvotes: 1

Harry Johnston
Harry Johnston

Reputation: 36328

Virtual bytes represent the processes use of the virtual address space, and don't necessarily represent memory usage, not even virtual memory usage. If the process is 32-bit, don't worry about this statistic unless it is the best part of a gigabyte or more, and if the process is 64-bit don't worry about it full stop.

Mark Russinovich’s blog entry Pushing the Limits of Windows: Virtual Memory provides more detail on this.

The statistic you probably want to look at instead is Page File Bytes. Private Bytes and Working Set may also be of interest. These are described under Process Object in the Technet documentation on the Windows Server 2003 Performance Counters Reference.

Upvotes: 1

Related Questions