question about AWE and /PAE

I have a question about the /3gb /pae switch that I was wondering if
someone could shed some light on.
My understanding is that when windows has a machine with 4GB of memory
2GB is reserved as usermode and 2gb is reserved for kernal mode. (This
is without using the /3gb switch)
My server has 5GB of memory. AWE is enabled and max server memory and
min server memory is set to 4125. I am using the /PAE switch but NOT
the /3GB
based on this the max memory that the SQL Server process shoudl have
access to is 3GB
2GB - Kernel Mode
2GB - User Mode
1GB - Access via AWE
But when I run perfmon and look at Total Server Memory this value
is 4125. How is this possible without using the /3GB switch?
Shouldn't this value be only 3GB?
Bert
What you see is correct. AWE does not require PAE or /3GB or any special OS
edition to do it's business.
PAE only helps it to see mem above 4 GB when available.
KB 274750 is the most correct source, I wouldn't trust anything else, there
are plenty of misleading publications about AWE :-)
Best practices would be another topic, but I am not certain that you have
the best config.
5GB gives you only 1 GB benefit vs 4GB + life without PAE-AWE, but you're
getting all the PAE-AWE overhead and bugs for this extra gig.
I'd pump memory up to 8GB to fully justify PAE-AWE, or sacrificed 1GB and
use /3GB only on a 4GB system if that doesn't hurt page life expectancy.
Regards,
AD
"bert" <bertcord@.gmail.com> wrote in message
news:1110229420.102441.138830@.z14g2000cwz.googlegr oups.com...
> I have a question about the /3gb /pae switch that I was wondering if
> someone could shed some light on.
> My understanding is that when windows has a machine with 4GB of memory
> 2GB is reserved as usermode and 2gb is reserved for kernal mode. (This
> is without using the /3gb switch)
> My server has 5GB of memory. AWE is enabled and max server memory and
> min server memory is set to 4125. I am using the /PAE switch but NOT
> the /3GB
> based on this the max memory that the SQL Server process shoudl have
> access to is 3GB
> 2GB - Kernel Mode
> 2GB - User Mode
> 1GB - Access via AWE
> But when I run perfmon and look at Total Server Memory this value
> is 4125. How is this possible without using the /3GB switch?
> Shouldn't this value be only 3GB?
> Bert
>
|||Thanks for your reply Andrew; I am familiar with the article. However
I still don't understand the interaction of the /3GB switch and the
/PAE switch
I started looking into this more after Brian Moran's article in SQL
magazine this month. Based on Brain's article the KB you mentioned
and several other resources on the net I have come up with the
following conclusions.
1.AWE is used to access memory over 4GB
2.To enabled AWE you must specify the /PAE switch in the boot.ini
3.on a 32 bit OS 4GB of memory can be directly accessed
4.a default windows install on a machine with 4GB will allocated 2GB
to Usermode memory and 2GB to kernel mode memory
5.you can change the kernel mode \user mode allocation by using the
3GB switch in the boot.ini, this will change it to 3GB Usermode 1GB
Kernel mode
The problem is based on these conclusions I don't understand how my
server is using 4125MB of memory as it is not using the /3GB switch.
Can anyone help see anything wrong with my points above or can
explanation of how my server is using 4125MB of memory?
Bert
|||/PAE is an OS level switch that allows it to access more than 4GB of memory
by fooling it into thinking it is a 36 bit vs. 32 bit address space. The
/3GB is an app level (any app not just sql server) switch that lets the app
use up to 3GB (instead of the default of 2GB) of directly addressable ram.
Meaning the first 4GB. The reason SQL Server is using about 4GB is due to
the AWE setting which basically fools the app into thinking it is 36 bit
addressing as well. But in your case you are only using 2GB of directly
addressable memory and the other 2GB is thru AWE. Certain parts (most
actually) in sql servers memory allocation can only use the first 2GB (or
3GB if /3GB is turned on). The other 2GB is only used for the data buffer
cache. The buffer cache can also use memory below 2GB but the other parts
can not use above it. Hope that clears it up.
Andrew J. Kelly SQL MVP
"bert" <bertcord@.gmail.com> wrote in message
news:1110295182.235072.44080@.l41g2000cwc.googlegro ups.com...
> Thanks for your reply Andrew; I am familiar with the article. However
> I still don't understand the interaction of the /3GB switch and the
> /PAE switch
> I started looking into this more after Brian Moran's article in SQL
> magazine this month. Based on Brain's article the KB you mentioned
> and several other resources on the net I have come up with the
> following conclusions.
> 1. AWE is used to access memory over 4GB
> 2. To enabled AWE you must specify the /PAE switch in the boot.ini
> 3. on a 32 bit OS 4GB of memory can be directly accessed
> 4. a default windows install on a machine with 4GB will allocated 2GB
> to Usermode memory and 2GB to kernel mode memory
> 5. you can change the kernel mode \user mode allocation by using the
> 3GB switch in the boot.ini, this will change it to 3GB Usermode 1GB
> Kernel mode
> The problem is based on these conclusions I don't understand how my
> server is using 4125MB of memory as it is not using the /3GB switch.
> Can anyone help see anything wrong with my points above or can
> explanation of how my server is using 4125MB of memory?
> Bert
>
|||This article might help.
Inside SQL Server 2000's Memory Management Facilities
http://msdn.microsoft.com/library/de...v_01262004.asp
"bert" <bertcord@.gmail.com> wrote in message
news:1110229420.102441.138830@.z14g2000cwz.googlegr oups.com...
>I have a question about the /3gb /pae switch that I was wondering if
> someone could shed some light on.
> My understanding is that when windows has a machine with 4GB of memory
> 2GB is reserved as usermode and 2gb is reserved for kernal mode. (This
> is without using the /3gb switch)
> My server has 5GB of memory. AWE is enabled and max server memory and
> min server memory is set to 4125. I am using the /PAE switch but NOT
> the /3GB
> based on this the max memory that the SQL Server process shoudl have
> access to is 3GB
> 2GB - Kernel Mode
> 2GB - User Mode
> 1GB - Access via AWE
> But when I run perfmon and look at Total Server Memory this value
> is 4125. How is this possible without using the /3GB switch?
> Shouldn't this value be only 3GB?
> Bert
>
|||I did some more reading on AWE this evening and I am wondering what
the advantage of using /3GB when also using /PAE.
According to books-on-line
"The memory pool of an instance of SQL Server 2000 using AWE cannot
be swapped out to the page file"
So in my server example
2GB - Locked in memory, accessed using AWE.
2GB - Is directly addressed. This memory is also locked and can not
be paged to disk.
Now if I enabled /3GB in the boot.ini it would change to as follows
1GB - Locked in memory, accessed using AWE.
3GB - Is directly addressed. Memory is also locked and can not be
paged to disk.
The one thing I am not 100% on is if the user mode section of memory is
also locked. IS this true due to the fact that the SQL Server is using
AWE?
Thanks
Bert
|||
> 1. AWE is used to access memory over 4GB
It is rather over 2GB for an application.

> 2. To enabled AWE you must specify the /PAE switch in the boot.ini
Not true.
You probably have many links telling opposite :-)

> 3. on a 32 bit OS 4GB of memory can be directly accessed
true

> 4. a default windows install on a machine with 4GB will allocated 2GB
> to Usermode memory and 2GB to kernel mode memory
true

> 5. you can change the kernel mode \user mode allocation by using the
> 3GB switch in the boot.ini, this will change it to 3GB Usermode 1GB
> Kernel mode
true. That's for direct access.
AWE can be used instead for a "cheat" method if app supports it.

> The problem is based on these conclusions I don't understand how my
> server is using 4125MB of memory as it is not using the /3GB switch.
It is using AWE instead
|||You never want any memory that sql server uses to be paged to disk. That is
the whole point of sql server having it's own caching mechanism. If you
turn on AWE you need to ensure that you set your max memory setting to an
amount less than the total amount of memory so the OS always has access to
some.
Andrew J. Kelly SQL MVP
"bert" <bertcord@.gmail.com> wrote in message
news:1110342099.812640.6560@.f14g2000cwb.googlegrou ps.com...
>I did some more reading on AWE this evening and I am wondering what
> the advantage of using /3GB when also using /PAE.
> According to books-on-line
> "The memory pool of an instance of SQL Server 2000 using AWE cannot
> be swapped out to the page file"
> So in my server example
> 2GB - Locked in memory, accessed using AWE.
> 2GB - Is directly addressed. This memory is also locked and can not
> be paged to disk.
> Now if I enabled /3GB in the boot.ini it would change to as follows
> 1GB - Locked in memory, accessed using AWE.
> 3GB - Is directly addressed. Memory is also locked and can not be
> paged to disk.
> The one thing I am not 100% on is if the user mode section of memory is
> also locked. IS this true due to the fact that the SQL Server is using
> AWE?
> Thanks
> Bert
>
|||I appreciate everyone trying to help me...but... my question is still
not answered. Maybe If I ask a different question it will help.
Ok lets take my example
1.SQL Server Enterprise on windows 2000 Advanced server
2.Server has 5GB of memory
3./PAE is enabled
4.NO /3GB is used
5.AWE is enabled in SQL server
6.max server memory is not set
According to books online
"If max server memory has not been set and there is at least 3 GB of
free memory available on the computer, then the instance acquires
almost all of the available memory and may leave only up to 128 MB of
memory free."
Also from books-on-line
"Windows 2000 may require at least 1 GB of available memory to manage
AWE"
ok so in this example the server takes all memory but 128MB...... So
what about the second statement above? Where is the kernel mode memory
that windows need to use to manage the AWE memory? The server only has
128MB left...so I am assuming that it is paged out to disk.
I want to make sure that enough memory is left for the OS to manage the
AWE memory. The kernel mode section of memory manages this so you
should make sure SQL leaves enough physical memory so that the kernel
memory is not paged out to disk.
Thanks again
Bert
|||The statement that it may take up to 1GB to manage AWE is hypothetical. If
you have upwards of 16GB and are using AWE the OS may actually need all 2GB
to operate properly. You always have to set a MAX memory when using AWE
otherwise SQL Server will allocate and lock all but 128MB and leave very
little for the OS. I never recommend leaving less than 1GB to start for the
OS.
Andrew J. Kelly SQL MVP
"bert" <bertcord@.gmail.com> wrote in message
news:1110381394.812121.45160@.z14g2000cwz.googlegro ups.com...
>I appreciate everyone trying to help me...but... my question is still
> not answered. Maybe If I ask a different question it will help.
> Ok lets take my example
> 1. SQL Server Enterprise on windows 2000 Advanced server
> 2. Server has 5GB of memory
> 3. /PAE is enabled
> 4. NO /3GB is used
> 5. AWE is enabled in SQL server
> 6. max server memory is not set
> According to books online
> "If max server memory has not been set and there is at least 3 GB of
> free memory available on the computer, then the instance acquires
> almost all of the available memory and may leave only up to 128 MB of
> memory free."
> Also from books-on-line
> "Windows 2000 may require at least 1 GB of available memory to manage
> AWE"
> ok so in this example the server takes all memory but 128MB...... So
> what about the second statement above? Where is the kernel mode memory
> that windows need to use to manage the AWE memory? The server only has
> 128MB left...so I am assuming that it is paged out to disk.
> I want to make sure that enough memory is left for the OS to manage the
> AWE memory. The kernel mode section of memory manages this so you
> should make sure SQL leaves enough physical memory so that the kernel
> memory is not paged out to disk.
> Thanks again
> Bert
>