[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 738
  • Last Modified:

Learning about RAM, virtual memory etc

Hi

I'm trying to understand the relationship between virtual memory, RAM, page files etc. I've been reading the internet especially:

http://members.shaw.ca/bsanders/WindowsGeneralWeb/RAMVirtualMemoryPageFileEtc.htm

"...application programs and many system processes always reference memory using virtual memory addresses which are automatically translated to real (RAM) addresses by the hardware"

So in my example, let's say we have a Windows 2008 Server with 2GB RAM installed. Am I right in thinking that:

i. Regardless of the amount of physical memory, there is 4GB of virtual memory allocated for each process running. 2GB of this is for the process itself, 2GB for the OS

Question1: I assume this is for an x32 OS, what about an x64 OS [running on x64 hardware]

Question 2: Even if we had a x64 hardware, but x32 OS, I assume we still only have 4GB virtual address space

Question 3: Is this 4 GB virtual memory PER PROCESS, or is it for all processes added together?

Question 4: If it is for each process (i.e. each process has 4GB virtual memory) why does there need to be 2 GB reserved for the OS? What exactly does this "reserved for the OS" allocation do?

Question 5. So if I had 3 apps running on my server, each with their own process, does this mean that we would have 3 x 4GB virtual memory allocations going on?

"..The main thing is that space in the page file will be allocated to virtual memory pages for which no corresponding RAM page is available".

Question 6: Is it true to say that the page file is used ONLY when there is no physical RAM left? Are the following two the best monitors for Page file use:

Memory: Pages Input/Sec
Memory Pages Output/sec

 Question 7: If we use a Windows 2008 Enterprise x64 version of the OS, do we remove all these problems with Page File etc, since we can allocate so much RAM??

Question 8: On a Windows 2008 x32 OS (either Standard or Enterprise), is it true to say that there is no point installing more than 4GB RAM, since the OS cannot see it?
0
neil4933
Asked:
neil4933
  • 4
  • 2
1 Solution
 
Frosty555Commented:
Lets back up a little bit... you're mixing up a few things.

First, lets talk about an IDEAL, theoretical concept of how virtual/physical RAM works, in simple terms:

1) The computer has a certain fixed amount of physical memory. It is addressable by the hardware (lets say for example that the addresses go from 0 to 65535)

2) Each applications does not get to actually the phyiscal memory directly and it never knows what the real physical addresses is. Instead, they get a "virtual" address. When they attempt to access memory, the virtual address is "automagically" converted into the physical address, and this is used to access the memory. The component that performs that conversion is called the "Memory Management Unit", or the MMU.

This process has NOTHING to do with pagefiles, swapping, etc. We're just talking about regular RAM so far.

So for example, lets say we have Excel, Word, and Firefox open. Each program would be assigned memory:

        Excel
             (assigned memory addresses 0 to 500)
        Word
             (assigned memory addresses 0 to 500)
        Firefox
             (assigned memory addresses 0 to 500)

In reality, these three blocks of memory could be stored in addresses 605-1105, 102-602, and  1423-1923 respectively.

Why is this useful?

Because it means the applications does not need not know how or where the memory is stored. This provides the operating system and hardware with many conveniences:

- Applications can be prevented from reading or modifying each other's memory, essentially isolating them from each other. Blocks of memory can be reserved and cannot be touched by any application

- Applications can access memory in a sequential virtual block, even if the physical storage of that memory is fragmented and scattered across the actual physical memory. The application programmer need not concern themselves with it.

- The system can rearrange memory or move things around, and the application doesn't need to know about it

- A 32-bit application running on a 64-bit OS can be given a block of memory that is physically located in an upper space >4GB, in a location that the application would not normally be able to address

You can see how the "virtual" memory system, in an ideal world, has many advantages, but has NOTHING to do with pagefiles, swap files etc.

In other contexts, "virtual" memory can refer to the Windows operating system's process of storing application memory on a file in the hard drive.

The specifics and caveats vary from one operating system and architecture to another but are secondary to the core concept of virtual/physical memory allocation.
0
 
Frosty555Commented:
The next core concept to cover is "swap files". Windows also refers to this as "virtual memory", but it is a different concept than what I talked about above. Really, it just refers to the technique used by the operating system to utilize hard disk space as additional memory.

The operating system allocates space on the hard drive for the purpose of storing the pagefile. When the operating system detects that it is running short on physical memory, it offloads some of the physical memory into the pagefile in order to make space.

If an application ever attempts to access a block of memory, and that memory has been offloaded into the pagefile, the application must WAIT for the operating system to clear some space in physical memory and load it back in from the hard disk. That is to say, neither applications nor the OS ever actually reads from the pagefile directly, rather memory is "swapped" in and out of the pagefile into RAM whenever an application needs it.

For this reason, the OS tries to put the oldest, most rarely used memory into the pagefile in order to make space in RAM for the more frequently accessed blocks. This helps speed up the computer. There are various tricks the OS employs in order to decide what goes into the pagefile and when.

In particular, the OS will preemptively "swap" and minimized application into the pagefile to make room for the currently active application, so that if it needs to allocate more memory it is immediately available.

This memory swapping and paging is done entirely in software - the hardware is not responsible for these actions. So the performance and behavior of pagefiles and swap files varies greatly from one OS (e.g. Windows) to another (e.g. Linux).
0
 
Frosty555Commented:
Regarding your questions, I'll try to answer as many as I can:

i. Regardless of the amount of physical memory, there is 4GB of virtual memory allocated for each process running. 2GB of this is for the process itself, 2GB for the OS

No. The operating system is capable of allocating a total amount of "virtual" memory which is comprised both of the pagefile, AND of the 2GB of physical memory, but each process is only assigned as much memory as it actually needs.

In a 32-bit Windows environment, the operating system has a (annoying an unnecessary) limitation of it's memory management in that it dedicates 2GB of addressable memory to itself, and the other 2GB goes to applications. If applications use more than 2GB of memory, it will start swapping data in and out of the pagefile regardless of the fact that more RAM exists on the system. It's an inefficiency and it's annoying, but it doesn't actually have anything to do with the theoretical concept of how memory works.

Question1: I assume this is for an x32 OS, what about an x64 OS [running on x64 hardware]

The 2gb limitation has been corrected in 64-bit OS. (also note that the proper terminology is x86 architecture for 32-bit software, and x64 architecture for 64-bit software, there's no such thing as x32).

Question 2: Even if we had a x64 hardware, but x32 OS, I assume we still only have 4GB virtual address space

That is correct. The operating system is limited to the architecture it was designed for even if your hardware is capable of more.

There's lots of technicalities and caveats as to what the ACTUAL maximum amount of memory an OS can use is, but 4GB is an approximate limitation. The rest of the physical memory is wasted.

Question 3: Is this 4 GB virtual memory PER PROCESS, or is it for all processes added together?

It is entirely dependent on the OS. For 32-bit OS (e.g. Windows XP), you're actually limited to 2GB of memory, TOTAL, for all applications combined, before swapping occurs.

For 32-bit applications running on a 64-bit OS, they are limited to addressing 4GB of memory, even though they COULD be allocated more, they won't be able to address it, but that's a limitation of the application, not the OS.

Any other limitations as far as how much memory an application can allocate is specific to the operating system, and you need to look it up.

Question 4: If it is for each process (i.e. each process has 4GB virtual memory) why does there need to be 2 GB reserved for the OS? What exactly does this "reserved for the OS" allocation do?

It's not for each process. In this question you are talking about the technical limitation of older 32-bit Windows OS that it reserves 2GB of physically available memory for itself, and 2GB of memory for applications.

The reservation was a design decision made on Microsoft's part. The reasons for it are technical, but probably have something to do with isolating the operating system from the applications.

Question 5. So if I had 3 apps running on my server, each with their own process, does this mean that we would have 3 x 4GB virtual memory allocations going on?


No. Applications only allocate as much memory as they need, but there are sometimes limitations as to how much memory the operating system is willing to give them. Whether or not this memory is referencing a place in the pagefile vs a place in physical memory is up to the operating system to decide, but when the application eventually decides to READ that block of memory, the OS will need to swap it back into RAM before letting the application go ahead with the read operation.

Question 6: Is it true to say that the page file is used ONLY when there is no physical RAM left? Are the following two the best monitors for Page file use:

Memory: Pages Input/Sec
Memory Pages Output/sec


No, the page file is used all the time and the exact algorithm for when the OS decides what to put into the pagefile and when is very complicated and proprietary, and varies greatly from Windows XP to 7, and from Server 2003 to Server 2008.

Sorry, I don't think that Pages/sec is the correct performance counter to examine. I think that counter just refers to how much memory an application is accessing, period. Regardless of whether the memory accesses are happening exclusively in physical RAM, or if it is requiring the OS to swap memory in and out of the pagefile.

Question 7: If we use a Windows 2008 Enterprise x64 version of the OS, do we remove all these problems with Page File etc, since we can allocate so much RAM??

No, technically there is no "problem". The OS will attempt to make the most efficient use of the physically available RAM by occasionally putting things into the pagefile when it things they aren't being used.

Even if the OS is 64-bit and is capable of accessing large addresses of memory, it does not change the behavior of how the pagefile works, they are totally separate concepts.

Question 8: On a Windows 2008 x32 OS (either Standard or Enterprise), is it true to say that there is no point installing more than 4GB RAM, since the OS cannot see it?

That is correct. In each OS has an intentionally set "maximum" that it adheres to, and there is no point putting more than that amount of memory in period.

Refer to the charts in the link below to determine the maximum amount of memory your OS supports:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).aspx

Interesting fact- Windows 7 Home Premium supports a max of 16GB of memory. There's no point putting more in even if your motherboard supports it.
0
Fill in the form and get your FREE NFR key NOW!

Veeam is happy to provide a FREE NFR server license to certified engineers, trainers, and bloggers.  It allows for the non‑production use of Veeam Agent for Microsoft Windows. This license is valid for five workstations and two servers.

 
Frosty555Commented:
Whoops I need to correct myself.

The operating system imposes several limitations on how much memory each process is allowed to allocate, and how much memory TOTAL the OS will allocate for processes and for itself.

For all intents and purposes you can assume these limitations are arbitrary and made either for technical reasons, or for business reasons.

The core concepts of memory allocation I talked about above are still true, but the specific limitations and caveats to that ideal and simplified explanation are described in lots of depth in the link I gave above:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).aspx#memory_limits
0
 
neil4933Author Commented:
Excellent!! Thank you for the very comprehensive reply, I really appreciate it.

One thing I am still not sure upon...

Let's say I have four different processes running on my x86 Windows 2008 server.

Are you saying that there is one entity known as the virtual memory that can address up to 4GB. Each process can use different blocks of this virtual memory, but overall these processes can only use UP TO 2GB of virtual memory between them? It's not the case that each process itself can use up to 2GB of virtual memory?

In which case, if the above former statemement is correct, if this server had 4GB RAM installed, then no swapping would occur? Because since the processes can only use up to 2GB RAM collectively, and the rest is reserved for the OS, when would we ever exceed 4GB of virtual memory used?
0
 
neil4933Author Commented:
Anyone know the answer to my last point?
0

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

  • 4
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now