Working set, virtual bytes and private bytes

Question

Hello everyone,
I am using Windows Server 2003 Performance Counter tool to monitor the memory consumed by my process.
The interested terms are working set, virtual bytes and private bytes. My questions are,
1. If I want to watch the real physical memory consumed by current process, which one should I monitor?
2. If I want to watch the physical memory + swap file consumed by current process, which one should I monitor?
3. Any more clear description of what these terms mean? I read the help from Performance Counter tool, but still confused
which one(s) identifies the real used physical memory, and which one(s) identifies the real used physical memory + page swap file, and which one(s) identifies the required memory (may not be really allocated either in physical memory or in swap page file).
If there are any related learning resource about the concepts, it is appreciated if you could recommend some. :-)
thanks in advance,
George

Answer 1

And for further benefit:
"Virtual bytes" is the total size of the not-free virtual address space of the process. It includes private committed, mapped, physically mapped (AWE), and even reserved address spaces. 
"Private committed" is the portion of "virtual bytes" that is private to the process (as opposed to "mapped", which may be shared between processes; this is used by default for code). This normally includes program globals,
the stacks (hence locals), heaps, thread-local storage, etc. 
Each process's "private committed" memory is that process's contribution to the system-wide counter called "commit charge". There are also contributions to commit charge that aren't part of any one process, such as the paged pool. 
The backing store for "private committed" v.m. is the page file, if you have one; if you have (foolishly in my opinion) deleted your page file, then all private committed v.m., along with things like the paged pool that would normally be backed
by the page file, has to stay in RAM at all times... no matter how long ago it's been referenced (which is why I think running without a page file is foolish). 
The "commit limit" is the size of RAM that the OS can use (this will exclude RAM used for things like video buffers) plus the total of the current size(s) of your pagefile(s). Windows will not allow allocations of private committed address space
(e.g. VirtualAlloc calls with the COMMIT option) that would take the commit charge above the limit. If a program tries it, Windows will try to expand the page file (hence increasing the commit limit). If this doesn't succeed (maybe because page file expansion
is disabled, maybe because there's no free disk space to do it) then the attempt to allocate committed address space fails (e.g. the VirtualAlloc call returns with a NULL result, indicating no memory was allocated). 
The "Working set" is not quite "the subset of virtual pages that are resident in physical memory", unless by "resident" you mean "the valid bit is set in the page table entry", meaning that no page fault will occur
when they're referenced. But this ignores the pages on the modified and standby page lists. Pages lost from a working set go to one of these lists; if the modified list, they are written to the page file and then moved to the standby list. From there they
may be used for other things, such as to satisfy another process's  need for pages, or (in  Vista and later) for SuperFetch. But until that happens, they still contains the data from the process they came from and are still associated with that process
and with that processes' virtual pages. Referring to the virtual page for which the physical page is on the standby or modified list will result in a "soft" page fault that is resolved without disk I/O. Much slower than referring to a page that's
in the working set - but much faster than having to go to disk for it. 
So the most precise definition of "working set" is "the subset of virtual pages that can be referenced without incurring a page fault."