Answer 1
Private Bytes refer to the amount of memory that the process executable has asked for - not necessarily the amount it is actually using. They are "private" because they (usually) exclude memory-mapped files (i.e. shared DLLs). But - here's the catch - they don't necessarily exclude memory allocated by those files. There is no way to tell whether a change in private bytes was due to the executable itself, or due to a linked library. Private bytes are also not exclusively physical memory; they can be paged to disk or in the standby page list (i.e. no longer in use, but not paged yet either).
Working Set refers to the total physical memory (RAM) used by the process. However, unlike private bytes, this also includes memory-mapped files and various other resources, so it's an even less accurate measurement than the private bytes. This is the same value that gets reported in Task Manager's "Mem Usage" and has been the source of endless amounts of confusion in recent years. Memory in the Working Set is "physical" in the sense that it can be addressed without a page fault; however, the standby page list is also still physically in memory but not reported in the Working Set, and this is why you might see the "Mem Usage" suddenly drop when you minimize an application.
Virtual Bytes are the total virtual address space occupied by the entire process. This is like the working set, in the sense that it includes memory-mapped files (shared DLLs), but it also includes data in the standby list and data that has already been paged out and is sitting in a pagefile on disk somewhere. The total virtual bytes used by every process on a system under heavy load will add up to significantly more memory than the machine actually has.
So the relationships are:
- Private Bytes are what your app has actually allocated, but include pagefile usage;
- Working Set is the non-paged Private Bytes plus memory-mapped files;
- Virtual Bytes are the Working Set plus paged Private Bytes and standby list.
Answer 2
The priority of a process has nothing to do with memory use. The priority of a process is related to how much time that process has access to the CPU. When you set a process to realtime it is given the highest priority. This may sound good but it is usually a bad thing because it will then be able to block other processes. If you have a program which sometimes uses all of your CPU power and causes problems with other applications then lowering this may help. There is really never a need for you to raise this unless it is for an application which you have created. By default, most application that need this raised will do so upon installation.
BTW, if you have a multicore system then the priority matters far less because the system will also distribute the load across cores. If you have a multicore system you are going to have much better luck playing with the affinity of an application which adjust the preferred core it uses. Most of your apps will just use the first core. If you want better responsiveness from a certain app just put it on another core which isn't being used as much. Also, if you have hyperthreading then you'll want to keep in mind that the even numbered cores are bogus and should be thought of as just a small bonus to the previous core. It gets even more complicated if you are using dynamic overclocking and you have it configured for asymmetric clock speeds because in this case all of your core except the first will typically be underclocked untill you start doing something demanding. If this is the case you really don't want to mess with affinity unless you are sure that all of your cores are operating at full speed.
Regarding Q2, you might look at my answer here: http://superuser.com/questions/964382/how-do-priorities-work-on-task-manager-and-when-should-nt-i-set-this/964389#964389
– Jamie Hanrahan – 2015-09-01T22:16:54.610