Maximize memory usage on active-active sql cluster

we have an active-active sql cluster configured as follow:
server A - 4gb ram - sql server instance #1
server B - 4gb ram - sql server instance #2
currently each sql instance is configured to use at most 2gb of ram.
in case of failover, both instances switch on one server, effectively
usinge all 4gb without paging.
but it's quite a waste. under normal condition each server is not
using 2gb.
one option we are evaluating is configuring each server to use
min=1gb and max=3gb. and _disabling_ tha paging file.
disabling tha paging file should overcome the problem that, in case of
failover, the two instaces will start paging effectively rendering the
server unusable.
do you think it could work?
do you have any other suggestions?
thanks in advance,
cheers
/ettore
Hi
If you disable the paging file (which you can't as there is always some
kernel code paged out), then the other instance could not fail over as there
would be no RAM for it. So a failover cluster would be useless.
With the /3GB switch, user addressable memory limit is 3GB. The OS keeps 1Gb
for itself. Even with 2Gb, you are over committing memory. 1.5Gb maximum
should be your limit per instance to cater for failover.
Regards
Mike
"Ettore Pancini" wrote:

> we have an active-active sql cluster configured as follow:
> server A - 4gb ram - sql server instance #1
> server B - 4gb ram - sql server instance #2
> currently each sql instance is configured to use at most 2gb of ram.
> in case of failover, both instances switch on one server, effectively
> usinge all 4gb without paging.
> but it's quite a waste. under normal condition each server is not
> using 2gb.
> one option we are evaluating is configuring each server to use
> min=1gb and max=3gb. and _disabling_ tha paging file.
> disabling tha paging file should overcome the problem that, in case of
> failover, the two instaces will start paging effectively rendering the
> server unusable.
> do you think it could work?
> do you have any other suggestions?
> thanks in advance,
> cheers
> /ettore
>
|||thanks for answering Mike,
so, let's forget about disable paging. i understand it wont work.
and, thanks for pointing out the /3GB switch stuff wich I wasn't aware
of.
but, from BoL, reading from this page:
Dynamically Managing Memory Between Multiple Instances
exactly from this sentence "Once the amount of memory reaches the
point where only 4 MB to 10 MB is free, the instances begin competing
with each other for memory." and forward on. it seems that when in
competition, instances could free memory based on workload.
so suppose this scenario:
- instance configures as min=1.5GB, max=3.0GB
- normally each intance expand their usage to 3gb
- then one node fails
- instance wich was on the failing node is moved
- the two instances start competing
- the other instance starts to free memory
do you think it could work?
regarding paging, in the same article, BoL states that the dynamic
memory management algorithm will "ensures that the overall amount of
allocated memory remains under the level that would generate paging"
cheers, Ettore

> If you disable the paging file (which you can't as there is always some
> kernel code paged out), then the other instance could not fail over as there
> would be no RAM for it. So a failover cluster would be useless.
> With the /3GB switch, user addressable memory limit is 3GB. The OS keeps 1Gb
> for itself. Even with 2Gb, you are over committing memory. 1.5Gb maximum
> should be your limit per instance to cater for failover.
> Regards
> Mike
>
|||That's true, they can both live on the same node and compete for the
same 3GB of memory (one of my clusters is doing that at the moment in
fact). However, if they're both fairly active instances then data pages
will get swapped in and out of memory more often and the average page
life expectancy will be substantially reduced. My 2 instances are
normally fairly sedate in terms of memory allocation when on separate
nodes. At the moment they're allocating & deallocating pages in memory
like there's no tomorrow.
That's good if what you're after is to use all of your memory all of the
time. But if you're after a nice stable buffer cache then it would be
better not having them compete with each other for the same RAM.
Note bene, if you enable AWE memory in SQL (to allow a virtual address
space of more than 4GB for SQLServer; remember the kernel address space
is alway 1 or 2GB depending upon whether you enable /3GB or not) then
dynamic memory management is automatically turned off. This is because
to use physical memory above 4GB the process needs to lock pages in
memory and cannot swap pages out to disk. This means that SQL Server's
dynamic memory management goes out the window and you have to set a max
server memory limit for all instances that may reside on that node
(presumedly all nodes in the cluster have the same amount of physical
RAM) and the sum of those max server memory settings should be less than
the total physical RAM in presented to the O/S.
*mike hodgson* |/ database administrator/ | mallesons stephen jaques
*T* +61 (2) 9296 3668 |* F* +61 (2) 9296 3885 |* M* +61 (408) 675 907
*E* mailto:mike.hodgson@.mallesons.nospam.com |* W* http://www.mallesons.com
Ettore Pancini wrote:
[vbcol=seagreen]
>thanks for answering Mike,
>so, let's forget about disable paging. i understand it wont work.
>and, thanks for pointing out the /3GB switch stuff wich I wasn't aware
>of.
>but, from BoL, reading from this page:
>Dynamically Managing Memory Between Multiple Instances
>exactly from this sentence "Once the amount of memory reaches the
>point where only 4 MB to 10 MB is free, the instances begin competing
>with each other for memory." and forward on. it seems that when in
>competition, instances could free memory based on workload.
>so suppose this scenario:
>- instance configures as min=1.5GB, max=3.0GB
>- normally each intance expand their usage to 3gb
>- then one node fails
>- instance wich was on the failing node is moved
>- the two instances start competing
>- the other instance starts to free memory
>do you think it could work?
>regarding paging, in the same article, BoL states that the dynamic
>memory management algorithm will "ensures that the overall amount of
>allocated memory remains under the level that would generate paging"
>cheers, Ettore
>
>