Prev: How to determine if it's a CD or DVD in drive & RW possibly?
Next: Print Spooler Job ID Limit on Vista?
From: Pavel Lebedinsky [MSFT] on 12 Jan 2008 03:29
> My question is why sometimes from perfmon on Windows, working
> set larger than virtual memory? I think virtual memory is the total size
> of memory (committed, reserved, shared, private) and working set
> is just the RAM touched by current process currently.
> Virtual memory should always larger than working set...
>
> But, I write a simple program to show working set is larger than
> virtual memory from perfmon. The program is simple, just open a
> couple of memory map files and read from beginning to the end.

What do you mean by "virtual memory"? The Virtual Bytes counter
in perfmon is the one that includes both committed and reserved
pages. As you say, it should always be larger than the working set.

Before Vista, task manager had a counter called "VM Size" (in
Vista it was renamed to Commit Size) that was actually the same
as Private Bytes in perfmon. Private bytes may be smaller or
larger than working set depending on circumstances.

--
This posting is provided "AS IS" with no warranties, and confers no
rights.


From: Alexander Grigoriev on 12 Jan 2008 12:18

"Pavel Lebedinsky [MSFT]" <pavel(a)online.microsoft.com> wrote in message
news:%23ZKvKVPVIHA.5596(a)TK2MSFTNGP05.phx.gbl...
>
> Before Vista, task manager had a counter called "VM Size" (in
> Vista it was renamed to Commit Size) that was actually the same
> as Private Bytes in perfmon. Private bytes may be smaller or
> larger than working set depending on circumstances.
>

You mean it doesn't include executable pages from shared exe sections? This
makes sense, then.


From: Pavel Lebedinsky [MSFT] on 12 Jan 2008 21:04
>> Before Vista, task manager had a counter called "VM Size" (in
>> Vista it was renamed to Commit Size) that was actually the same
>> as Private Bytes in perfmon. Private bytes may be smaller or
>> larger than working set depending on circumstances.
>
> You mean it doesn't include executable pages from shared exe
> sections?

This also depends on circumstances :)

"Private bytes" is not an entirely accurate term. It is best to think
of it as the process commit charge. Process commit is charged
for all committed private allocations (private allocations are
reported as MEM_PRIVATE by VirtualQuery. They basically
include VirtualAlloc and everything built on top of it, like malloc).

Process commit is also charged when a process maps a copy-on-write
view of a section (executable or not). This memory is not private
(it will be either MEM_MAPPED or MEM_IMAGE depending
on what kind of section it was), but it can potentially become private
if the process writes to it, which is why commit has to be charged
in advance.

So in practice private bytes/process commit are typically larger
than the sum of all committed MEM_PRIVATE regions.

--
This posting is provided "AS IS" with no warranties, and confers no
rights.


From: George on 29 Jan 2008 21:50
Thanks Pavel,


Your reply is great.

1.

I am using Windows Server 2004, x64. You mean private bytes only count the
"real" commit ones, for example, the request for zero or copy-on-write
scenario, before pages are actually used, even if they are committed, they
are not counted as part of private bytes, right?

2.

Prvate bytes counter from perfmon always the same as commit charge from task
manager?

3.

In what situations do you think working set bytes counter could be larger
than virtual bytes counter in perfmon?


regards,
George

"Pavel Lebedinsky [MSFT]" wrote:

> >> Before Vista, task manager had a counter called "VM Size" (in
> >> Vista it was renamed to Commit Size) that was actually the same
> >> as Private Bytes in perfmon. Private bytes may be smaller or
> >> larger than working set depending on circumstances.
> >
> > You mean it doesn't include executable pages from shared exe
> > sections?
>
> This also depends on circumstances :)
>
> "Private bytes" is not an entirely accurate term. It is best to think
> of it as the process commit charge. Process commit is charged
> for all committed private allocations (private allocations are
> reported as MEM_PRIVATE by VirtualQuery. They basically
> include VirtualAlloc and everything built on top of it, like malloc).
>
> Process commit is also charged when a process maps a copy-on-write
> view of a section (executable or not). This memory is not private
> (it will be either MEM_MAPPED or MEM_IMAGE depending
> on what kind of section it was), but it can potentially become private
> if the process writes to it, which is why commit has to be charged
> in advance.
>
> So in practice private bytes/process commit are typically larger
> than the sum of all committed MEM_PRIVATE regions.
>
> --
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
>
>
From: George on 29 Jan 2008 21:51
Thanks Pavel,


> What do you mean by "virtual memory"? The Virtual Bytes counter
> in perfmon is the one that includes both committed and reserved

I mean Virtual Bytes counter in perfmon.


regards,
George

"Pavel Lebedinsky [MSFT]" wrote:

> > My question is why sometimes from perfmon on Windows, working
> > set larger than virtual memory? I think virtual memory is the total size
> > of memory (committed, reserved, shared, private) and working set
> > is just the RAM touched by current process currently.
> > Virtual memory should always larger than working set...
> >
> > But, I write a simple program to show working set is larger than
> > virtual memory from perfmon. The program is simple, just open a
> > couple of memory map files and read from beginning to the end.
>
> What do you mean by "virtual memory"? The Virtual Bytes counter
> in perfmon is the one that includes both committed and reserved
> pages. As you say, it should always be larger than the working set.
>
> Before Vista, task manager had a counter called "VM Size" (in
> Vista it was renamed to Commit Size) that was actually the same
> as Private Bytes in perfmon. Private bytes may be smaller or
> larger than working set depending on circumstances.
>
> --
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
>
>
 |  Next  |  Last
Pages: 1 2
Prev: How to determine if it's a CD or DVD in drive & RW possibly?
Next: Print Spooler Job ID Limit on Vista?