Recently, some of the clusters were under memory pressure and we had to consider turning on TPS to elevate memory pressure. Now in an ideal setting, you never need to do that because upper management always makes intelligent decisions and ensures that new VM demands are always met with at least 80% capacity. Also TPS, no matter how effeciency, essentially takes up CPU cycles. Of course, back in the real world demand always excess the capacity you have. Read the rest of this entry »
Tag Archives: memory
An interesting article from yellow bricks on an undocumented feature in Vsphere 6.0 to allow you to swap out memory after contention is long gone. Previously, you either had to power cycle or vmotion your VM to get back memory into RAM.
However, my advice is always to avoid over-commit of memory as the last resort and manage the size your VM to avoid over-commit whenever possible. Ballooning and memory swapping into disk is one of the most performance hit activities that can happen to your environment compared or over-committing on CPU.
Caught a few interesting blog talk about myths and misunderstanding of the 3GB and PAE switches.
This is another non sequitur. PAE increases the amount of physical memory that can be addressed by the processor, but that is unrelated to virtual address space. (Remember that PAE stands for Physical Address Extensions.)
PAE increases the physical address space (the address space that the CPU can use to access the memory chips on your computer) from 32 bits to 36 on a Pentium 2, for a theoretical maximum physical memory capacity of 64GB. However, the size of a pointer variable hasn’t changed. It’s still 32 bits (for a 32-bit processor), which means that the virtual address space is still 4GB.
It’s simple to explain what it does, but people often misunderstand.
The /3GB switch changes the way the 4GB virtual address space is split up. Instead of splitting it as 2GB of user mode virtual address space and 2GB of kernel mode virtual address space, the split is 3GB of user mode virtual address space and 1GB of kernel mode virtual address space.
As of Windows 2003 SP1 you should more than likely use /userva with /3GB if you need to use /3GB at all. I would choose a values around 2970 that would give you over 20,000 sysPTES’s free, which should allow the system to function without tipping over, but this is something that you’ll need to “tune” for your particular app. You also have to keep in mind that you’re reducing the space for the pools as well.
Really what you should do is reevaluate why you’re running 3GB in the first place, perhaps what you’re really looking for is PAE/AWE and just have 3GB in place by mistake. Also you should ask yourself, why am I NOT running an x64 hardware and OS?