It actually works the other way around. Put as much memory as you can in
each node. SQL will generally run better the more memory you give it. Then
divide the memory amongst the instances. Remember, during a failover, all
your instances will "stack" onto one server so you must plan for that
situation. Also you will need to leave 1-2GB for the OS and support
applications. Use the Performance Monitor tool to watchoverall memory use.
I like to use Page Life Expectancy as a measurement for memory pressure
within SQL Server.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
Thanks for the reply Geoff. I don't intend to run multiple instances per
node but only one instance per node. So lets say I have six servers now,
each using 2GB currently for the SQL server instance, then do I size 6GB
for the SQL instance per cluster node (in a cluster of two nodes).
- Siddhartha
> It actually works the other way around. Put as much memory as you can in
> each node. SQL will generally run better the more memory you give it. Then
[quoted text clipped - 20 lines]
>>
>>- Siddhartha
Geoff N. Hiten - 22 Nov 2005 14:07 GMT
During a cluster node failure event, the instances will all migrate to a
single node. That is how it wirks. You will need to divide the memory so
that both instances can live on a single node. As for total memory
required, there is no exact rule. SQL likes more memory so adding memory
won't hurt. Watch the performance counters to check memory pressure.
GNH
> Thanks for the reply Geoff. I don't intend to run multiple instances per
> node but only one instance per node. So lets say I have six servers now,
[quoted text clipped - 30 lines]
>>>
>>>- Siddhartha