M
Marty List
Here's a new tool I wrote, called MemCheck.exe. It's available as freeware.
http://www.optimumx.com/download/#MemCheck
I've been testing memory allocation in Windows Server 2003 using 3GB of
user-mode virtual memory per-process. Previously this feature was only
available in 2000 Advanced Server/ NT4 Enterprise Edition (the standard
editions only support 2GB per-process). Support for /3GB is now included in
the Standard Edition of Windows Server 2003 (I haven't tested the Web
Edition yet).
This is enabled by adding /3GB to the OS line of the boot.ini. If the OS
doesn't support /3GB it simply ignores it, so I couldn't find a way to
verify if this is actually working or not. I went through every memory and
process performance counter object and couldn't find one that showed this
(unless SQL Server is installed). So I wrote a quick C++ executable called
MemCheck.exe, and I also added another feature that I often want to do,
that's the ability to commit and lock memory, to experiment with how much
virtual and physical memory is currently available to new processes. I
didn't spend a lot of time on this one, so there may be bugs.
Here's a sample of the output:
C:\>MemCheck.exe
============================================================================
===
Physical Memory
============================================================================
===
TOTAL: 3807 MB of physical memory, 3898904 KB (33% used)
FREE: 2528 MB of physical memory, 2588948 KB (67% free)
============================================================================
===
Virtual Memory
============================================================================
===
TOTAL: 5731 MB of committed (physical+pagefile) memory, 5869204 KB (21%
used)
FREE: 4538 MB of committed (physical+pagefile) memory, 4647884 KB (79%
free)
============================================================================
===
Virtual Address Space
============================================================================
===
TOTAL: 1024 MB of kernel mode virtual memory
TOTAL: 3071 MB of user mode virtual memory for this process (01% used)
FREE: 3066 MB of user mode virtual memory for this process (99% free)
============================================================================
===
Extended (PAE) Memory
============================================================================
===
FREE: 0 MB of PAE memory for this process
The command completed successfully.
*** AND HERE'S THE SYNTAX ***:
C:\>MemCheck.exe /?
Memory Check [Version 1.00]
Displays information about the system's current memory statistics. Also
allows
you to commit and lock memory, to experiment with how much virtual and
physical
memory is currently available to new processes.
The syntax of this command is:
MemCheck.exe [/commit:#] [/lock]
/COMMIT: Allows you to commit a specified size of memory (in megabytes).
The maximum value allowed is 4095.
/LOCK causes the memory specified with /COMMIT to be locked into physical
memory. This ensures that subsequent access to the region will
not incur a page fault.
Examples:
MemCheck.exe /commit:1024
MemCheck.exe /commit:512 /lock
Legend:
1KB=1024 Bytes; 1MB=1024 KB; 1GB=1024 MB
An argument of /? or -? displays this syntax and always returns 1.
A successful completion will return 0.
**************
Memory management is a large and complicated subject, but here I'll try to
explain this portion of it in an easy to understand. Basically a standard
32-bit Windows application can only access (or reference) 4GB of virtual
memory. It doesn't matter how much physical memory is installed, or how big
the page file is, the largest number you can store with 32 bits is
4294967296:
2^32 = 4294967296
4294967296 / 1024 = 4194304 KB
4294967296 / 1024 / 1024 = 4096 MB
4294967296 / 1024 / 1024 / 1024 = 4 GB
So even if the machine has 6GB of physical and another 2GB of page file (8GB
virtual), when a 32-bit app asks the OS for memory, the most it even knows
how to ask for is 4GB (even though it could never actually get that much).
And of this 4GB, Windows breaks it up into 2GB for user-mode application use
and 2GB for OS use (this is global and includes kernel-mode drivers, etc).
So a standard 32-bit app on a default OS can not access more than 2GB of
virtual memory.
On certain versions of Windows, you can add /3GB to the boot.ini and this
4GB will be broken up into 3GB for user-mode and 1GB for kernel mode
(globally). From my testing, these versions of Windows support the /3GB
switch:
Windows NT4 Enterprise Edition
Windows 2000 Advanced Server
Windows 2000 Datacenter Server
Windows XP Professional
Windows Server 2003 Standard Edition (also supports /USERVA=)
Windows Server 2003 Enterprise Edition (also supports /USERVA=)
Windows Server 2003 Datacenter Edition (also supports /USERVA=)
* I haven't tested the Web Edition yet
Now even if the OS supports the /3GB option, each application also has to be
compiled as "3GB enabled" using the "/LARGEADDRESSAWARE" linker option (or
you can change the executable's image header later with imagecfg.exe). So a
standard 32-bit app, on any Windows OS, can not access more than 3GB of
virtual memory.
I haven't done this yet, but you can also develop applications that can
reference more than 4GB of memory using special APIs called AWE (Address
Window Extensions). If your system has more than 4GB of physical memory
installed you can enable this by adding /PAE to the boot.ini to enable
"Physical Address Extensions". But just adding /PAE to a machine with more
than 4GB will not change the limit of standard apps, they need to be
rewritten and recompiled to access the "extended" address space. SQL Server
2000 is the only app I know of that supports AWE, and it's not enabled by
default.
Remember this 2GB or 3GB limit applies to virtual memory, not physical
memory. Lets say you have an app that wants to access 3GB of memory, this
is possible even if you only have 2GB of physical memory, if you have at
least 2GB of page file (4GB virtual memory). Obviously your performance is
better if the machine has 4GB of physical memory.
Also remember this 2GB or 3GB limit is from a single process perspective, it
doesn't apply to the system as a whole. Lets say you have 5 processes
running concurrently and they all want access to 3GB of virtual memory, then
this should be possible if you have at least 16GB of total (virtual) memory
(3x15=15, +1GB for the OS/kernel). Now obviously you'll get the best
performance if the machine has 16GB of physical memory, but it should still
work if the machine has 12GB of physical memory and 4GB of page file.
Most of this changes with the 64-bit editions of Windows (but some of it's
still true when running 32-bit apps on 64-bit Windows). Let me know if you
got this far without falling asleep
Further reading:
Inside Memory Management, Part 1 (Mark Russinovich)
http://www.winnetmag.com/Article/ArticleID/3686/3686.html
Inside Microsoft Windows 2000, Third Edition (David Solomon and Mark
Russinovich)
http://www.sysinternals.com/insidew2k.shtml
http://www.optimumx.com/download/#MemCheck
I've been testing memory allocation in Windows Server 2003 using 3GB of
user-mode virtual memory per-process. Previously this feature was only
available in 2000 Advanced Server/ NT4 Enterprise Edition (the standard
editions only support 2GB per-process). Support for /3GB is now included in
the Standard Edition of Windows Server 2003 (I haven't tested the Web
Edition yet).
This is enabled by adding /3GB to the OS line of the boot.ini. If the OS
doesn't support /3GB it simply ignores it, so I couldn't find a way to
verify if this is actually working or not. I went through every memory and
process performance counter object and couldn't find one that showed this
(unless SQL Server is installed). So I wrote a quick C++ executable called
MemCheck.exe, and I also added another feature that I often want to do,
that's the ability to commit and lock memory, to experiment with how much
virtual and physical memory is currently available to new processes. I
didn't spend a lot of time on this one, so there may be bugs.
Here's a sample of the output:
C:\>MemCheck.exe
============================================================================
===
Physical Memory
============================================================================
===
TOTAL: 3807 MB of physical memory, 3898904 KB (33% used)
FREE: 2528 MB of physical memory, 2588948 KB (67% free)
============================================================================
===
Virtual Memory
============================================================================
===
TOTAL: 5731 MB of committed (physical+pagefile) memory, 5869204 KB (21%
used)
FREE: 4538 MB of committed (physical+pagefile) memory, 4647884 KB (79%
free)
============================================================================
===
Virtual Address Space
============================================================================
===
TOTAL: 1024 MB of kernel mode virtual memory
TOTAL: 3071 MB of user mode virtual memory for this process (01% used)
FREE: 3066 MB of user mode virtual memory for this process (99% free)
============================================================================
===
Extended (PAE) Memory
============================================================================
===
FREE: 0 MB of PAE memory for this process
The command completed successfully.
*** AND HERE'S THE SYNTAX ***:
C:\>MemCheck.exe /?
Memory Check [Version 1.00]
Displays information about the system's current memory statistics. Also
allows
you to commit and lock memory, to experiment with how much virtual and
physical
memory is currently available to new processes.
The syntax of this command is:
MemCheck.exe [/commit:#] [/lock]
/COMMIT: Allows you to commit a specified size of memory (in megabytes).
The maximum value allowed is 4095.
/LOCK causes the memory specified with /COMMIT to be locked into physical
memory. This ensures that subsequent access to the region will
not incur a page fault.
Examples:
MemCheck.exe /commit:1024
MemCheck.exe /commit:512 /lock
Legend:
1KB=1024 Bytes; 1MB=1024 KB; 1GB=1024 MB
An argument of /? or -? displays this syntax and always returns 1.
A successful completion will return 0.
**************
Memory management is a large and complicated subject, but here I'll try to
explain this portion of it in an easy to understand. Basically a standard
32-bit Windows application can only access (or reference) 4GB of virtual
memory. It doesn't matter how much physical memory is installed, or how big
the page file is, the largest number you can store with 32 bits is
4294967296:
2^32 = 4294967296
4294967296 / 1024 = 4194304 KB
4294967296 / 1024 / 1024 = 4096 MB
4294967296 / 1024 / 1024 / 1024 = 4 GB
So even if the machine has 6GB of physical and another 2GB of page file (8GB
virtual), when a 32-bit app asks the OS for memory, the most it even knows
how to ask for is 4GB (even though it could never actually get that much).
And of this 4GB, Windows breaks it up into 2GB for user-mode application use
and 2GB for OS use (this is global and includes kernel-mode drivers, etc).
So a standard 32-bit app on a default OS can not access more than 2GB of
virtual memory.
On certain versions of Windows, you can add /3GB to the boot.ini and this
4GB will be broken up into 3GB for user-mode and 1GB for kernel mode
(globally). From my testing, these versions of Windows support the /3GB
switch:
Windows NT4 Enterprise Edition
Windows 2000 Advanced Server
Windows 2000 Datacenter Server
Windows XP Professional
Windows Server 2003 Standard Edition (also supports /USERVA=)
Windows Server 2003 Enterprise Edition (also supports /USERVA=)
Windows Server 2003 Datacenter Edition (also supports /USERVA=)
* I haven't tested the Web Edition yet
Now even if the OS supports the /3GB option, each application also has to be
compiled as "3GB enabled" using the "/LARGEADDRESSAWARE" linker option (or
you can change the executable's image header later with imagecfg.exe). So a
standard 32-bit app, on any Windows OS, can not access more than 3GB of
virtual memory.
I haven't done this yet, but you can also develop applications that can
reference more than 4GB of memory using special APIs called AWE (Address
Window Extensions). If your system has more than 4GB of physical memory
installed you can enable this by adding /PAE to the boot.ini to enable
"Physical Address Extensions". But just adding /PAE to a machine with more
than 4GB will not change the limit of standard apps, they need to be
rewritten and recompiled to access the "extended" address space. SQL Server
2000 is the only app I know of that supports AWE, and it's not enabled by
default.
Remember this 2GB or 3GB limit applies to virtual memory, not physical
memory. Lets say you have an app that wants to access 3GB of memory, this
is possible even if you only have 2GB of physical memory, if you have at
least 2GB of page file (4GB virtual memory). Obviously your performance is
better if the machine has 4GB of physical memory.
Also remember this 2GB or 3GB limit is from a single process perspective, it
doesn't apply to the system as a whole. Lets say you have 5 processes
running concurrently and they all want access to 3GB of virtual memory, then
this should be possible if you have at least 16GB of total (virtual) memory
(3x15=15, +1GB for the OS/kernel). Now obviously you'll get the best
performance if the machine has 16GB of physical memory, but it should still
work if the machine has 12GB of physical memory and 4GB of page file.
Most of this changes with the 64-bit editions of Windows (but some of it's
still true when running 32-bit apps on 64-bit Windows). Let me know if you
got this far without falling asleep
Further reading:
Inside Memory Management, Part 1 (Mark Russinovich)
http://www.winnetmag.com/Article/ArticleID/3686/3686.html
Inside Microsoft Windows 2000, Third Edition (David Solomon and Mark
Russinovich)
http://www.sysinternals.com/insidew2k.shtml