Memory allocation for complex cluster setup

Greetings. Having some difficulty consolidating on the appropriate memory
setup for the following configuration:
2 node cluster, Windows 2003 Enterprise Edition SP1 with SQL 2000 Enterprise
Edition SP4. There are 6 virtual SQL servers installed. Generally we run
one (primary) virtual server all by itself on the first node, and the other 5
(secondary) all bunched up on the second node. The primary virtual server
has recently begun having problems with performance. We are hung up on a
debate over the proper memory configuration. Both nodes have 10.0 GB of RAM.
We already have /PAE set on both nodes. We intentionally have not set /3GB
switch in the past, because in the event of a node failure, all 6 SQL
instances will end up on one node, possibly using 12.0GB of RAM, and causing
it's own problems. The virtual SQL servers all actually max out at about 1.7
GB (at least I have never seen them any higher), I assume that is some SQL or
OS quirk that keeps it close to 2.0GB max.
Now we are at the point where the primary virtual servers performance, even
when it is sitting all by itself, is becoming an issue. The Microsoft
documentation says for 8GB to use /3GB and /PAE. For 16GB to use /PAE
without /3GB, because if you accidentally cut off OS RAM to 1GB, you will
cause problems for the /PAE when addressing 16GB. Also, I have seen some
Microsoft documents that say "Generally you will not need to use AWE and /3GB
at the same time." My understanding is that /3GB actually is sort of "false
advertising", in that it was intended for 4GB systems. It really just tells
the OS to only reserve 1GB for itself, and give the rest to applications
(generally 3GB).
So here are the actual questions:
If I use /PAE WITHOUT /3GB on a system with 10.0GB, and then turn on SQL AWE
and set the max SQL RAM to 8.0GB, is that any different than if I use /PAE
AND /3GB on the same system, turn on AWE and set the max SQL RAM to 8.0GB?
What if I do both scenarios with a max SQL RAM of 9.0GB? Since I only have
10.0GB, will SQL be refused the extra 1.0GB in the scenario without the /3GB
switch because 2.0GB are reserved for the OS?
And finally, in my real world case, SQL is only ever using that 1.7 GB right
now... Should I start by just adding the /3GB switch without turning on AWE
in SQL to see if can even find use for the extra 1.0GB available before going
over the top and assigning an extra 6.0 GB or 7.0 GB? Will SQL actually make
use of all that RAM?
I know that is mostly theoretical. Hoping an expert can share some
understanding with me on what is otherwise guesswork on my part.
- Dan
dbanick@.axentis.comThe /3GB really has nothing to do with AWE other than the fact you should
not turn it on when you are using 12GB or more. THis is because the OS
needs more memory to handle the PTE's and such with the more memory above
4GB it has to manage. 16GB is a hard cut off but 12 is my practical limit.
Your issue is not so much the /3GB but the AWE. If you turn on AWE you will
have effectively choked out the other instances if they fail over to that
machine. AWE memory in SQL2000 is not dynamic. That is one of the main
reasons why you need to set an upper limit with the MAX Memory setting. YOu
have to be extremely careful when using AWE in a cluster due to that fact.
In SQL2005 AWE can be dynamic and you don't have to worry as much about it.
--
Andrew J. Kelly SQL MVP
"Dan Banick" <Dan Banick@.discussions.microsoft.com> wrote in message
news:31AE3BA6-C00D-4435-A876-A2A4B3042ADB@.microsoft.com...
> Greetings. Having some difficulty consolidating on the appropriate memory
> setup for the following configuration:
> 2 node cluster, Windows 2003 Enterprise Edition SP1 with SQL 2000
> Enterprise
> Edition SP4. There are 6 virtual SQL servers installed. Generally we run
> one (primary) virtual server all by itself on the first node, and the
> other 5
> (secondary) all bunched up on the second node. The primary virtual server
> has recently begun having problems with performance. We are hung up on a
> debate over the proper memory configuration. Both nodes have 10.0 GB of
> RAM.
> We already have /PAE set on both nodes. We intentionally have not set
> /3GB
> switch in the past, because in the event of a node failure, all 6 SQL
> instances will end up on one node, possibly using 12.0GB of RAM, and
> causing
> it's own problems. The virtual SQL servers all actually max out at about
> 1.7
> GB (at least I have never seen them any higher), I assume that is some SQL
> or
> OS quirk that keeps it close to 2.0GB max.
> Now we are at the point where the primary virtual servers performance,
> even
> when it is sitting all by itself, is becoming an issue. The Microsoft
> documentation says for 8GB to use /3GB and /PAE. For 16GB to use /PAE
> without /3GB, because if you accidentally cut off OS RAM to 1GB, you will
> cause problems for the /PAE when addressing 16GB. Also, I have seen some
> Microsoft documents that say "Generally you will not need to use AWE and
> /3GB
> at the same time." My understanding is that /3GB actually is sort of
> "false
> advertising", in that it was intended for 4GB systems. It really just
> tells
> the OS to only reserve 1GB for itself, and give the rest to applications
> (generally 3GB).
> So here are the actual questions:
> If I use /PAE WITHOUT /3GB on a system with 10.0GB, and then turn on SQL
> AWE
> and set the max SQL RAM to 8.0GB, is that any different than if I use /PAE
> AND /3GB on the same system, turn on AWE and set the max SQL RAM to 8.0GB?
> What if I do both scenarios with a max SQL RAM of 9.0GB? Since I only
> have
> 10.0GB, will SQL be refused the extra 1.0GB in the scenario without the
> /3GB
> switch because 2.0GB are reserved for the OS?
> And finally, in my real world case, SQL is only ever using that 1.7 GB
> right
> now... Should I start by just adding the /3GB switch without turning on
> AWE
> in SQL to see if can even find use for the extra 1.0GB available before
> going
> over the top and assigning an extra 6.0 GB or 7.0 GB? Will SQL actually
> make
> use of all that RAM?
> I know that is mostly theoretical. Hoping an expert can share some
> understanding with me on what is otherwise guesswork on my part.
> - Dan
> dbanick@.axentis.com