In an earlier article, I wrote about the difference between Virtual Memory and Physical Memory as it relates to Microsoft Access development.
Here's a brief synopsis:
- Physical Memory = RAM (fast, but expensive and limited capacity)
- Virtual Memory = Hard Disk (slow, but cheap and plentiful)
- Virtual memory is more important in 32-bit Access (due to limited address space)
- Physical memory is more important in 64-bit Access (since the address space is unlimited for practical purposes)
One question you might be asking is, "How do virtual machines (VMs) fit into that discussion?" Virtual machines are virtual, after all. It's right there in the name. Can a virtual machine even have physical memory?
Physical Memory for Virtual Machines
When you configure a virtual machine (VM), you allocate a certain amount of memory to the machine, say 2 GB.
Once this has been allocated, the VM acts as though that 2 GB is physical memory.
How the host operating system provides that memory can vary. In some cases, the host reserves a full 2 GB of hardware RAM for the VM. Since the host needs additional RAM for the overhead of managing the VM itself, the total amount of committed memory is probably in the neighborhood of 2.1 GB to 2.5 GB.
Some VM server implementations act like commercial airlines.
As you probably know, most airlines overbook their flights. If a plane has 100 seats, they might sell 105 tickets anticipating that at least five customers will be a no-show. But what happens if all 105 customers check in? Five of them will not be on the plane: they'll either have to wait their turn for the next flight OR rent a car. Either way, it's going to take way longer than planned for those five.
Like these airlines, certain VM servers will overbook their RAM allocation. For example, a server might have 10 VMs each with 2 GB of RAM configured. However, the server might only set aside 16 GB of physical RAM for these VMs, assuming that the aggregate RAM usage will stay below 80%.
What happens if the VM server runs out of physical RAM in that scenario? It would backfill with Virtual RAM. That is, it would start writing to the hard disk instead of to physical RAM. This would all be completely transparent to the VM, other than the fact that its RAM performance would suddenly take a major hit.
Let's go back to the airline analogy. Imagine Grandma is flying from Orlando to New York to visit for Thanksgiving. Unfortunately, her flight into LaGuardia (physical RAM) is overbooked, so the airline puts her on a Greyhound bus instead (virtual RAM). The airline arranges for the bus to drop her off at the baggage claim area in LaGuardia. So, to you (the application), how Grandma got to LaGuardia is completely transparent; you're still picking her up at baggage claim. The problem is that you're there Wednesday evening to meet her, but she doesn't actually show up until Black Friday (major performance hit).
So, just because the situation is transparent, that doesn't make it meaningless. This type of situation is a classic case of a leaky abstraction.
The question you're probably asking yourself is,
"How does this affect me as an Access developer?"
The most obvious way it affects you is when configuring the RAM for a virtual machine.
If you will be running 32-bit Access in your VM, there's no point in allocating more than 2 GB of RAM to the VM (unless you will also be running a bunch of other applications on the VM at the same time). That's because 32-bit Access can only address 2 GB of address space (assuming you haven't modified msaccess.exe with the Large Address Aware flag).
On the other hand, you need to be careful assuming you have massive amounts of memory simply because you know your end users will be running 64-bit Office. While it is unusual to see physical workstations with less than 4 GB of RAM these days, VMs with only 1 or 2 GB of assigned memory are not uncommon.
Do any of your Access applications run in production on virtual machines? If so, let me know in the comments below what, if anything, you've had to adjust in your development to deal with the memory situation.