在SQL Server 2005和2008中使用多实例故障转移群集（曾经被称为主动 – 主动）时，我想知道你configuration了最小和最大服务器内存。
对于双节点多实例群集（每个节点有两个实例），最佳做法是将每个实例的最servlets器内存configuration为40-45％，以便在发生故障转移时两个实例不最终导致内存数量极度不平衡，因为新实例可能会对已经运行的实例施加不适当的内存压力。
虽然这是一个最佳实践，但我想听到有这种情况的人 – 你为不同的实例configuration了什么内存设置？ 你是否让他们平等，或者你在每个实例上运行的工作负载的优先级？ 你使用WSRM吗？ 您是否根据故障后转移群集configurationdynamic更改内存设置？
谢谢！
PS我不需要关于内存pipe理如何工作的信息，或者为什么存在最佳实践 – 我知道所有这一切 – 我对人们在做什么感兴趣。
PPS请注意，我对SQL 2000不感兴趣 – 内存pipe理器没有响应这种内存压力，所以最好的做法是将最大服务器内存设置为每个实例50％。 育。
刚刚为客户做了这个。 他们在每个节点上有16Gigs，每个节点使用8Gigs。 有一个例子是需要更多的内存，所以我们把它提高到了12，并且提醒设置来监视SQL重启并发出一条消息。 如果由于硬件故障导致故障切换，则应手动降低硬件，直到硬件修复。
在我们的环境中，我们有几个多实例集群，根据实例的目的 ，我们有所不同。 在我们的prod-prod集群中，每个节点上都有32Gb。 我们为非SQL（O / S，磁带备份过程，反病毒等）保留4，然后将剩下的RAM减半（每个节点32-4 = 28/2 = 14Gb）。这些是最大值，我们为每个设置了一个8Gb的分钟。
在我们的产品testing集群中，我们偏向于产品（显然）。 Prod接收20Gb的最大设置，testing有8Gb。 8Gb的分钟保持不变。
如果我们正在积极地进行testing，并希望确保我们的testing与产品之间的设置匹配，则可以调整这些值。 我们提前安排这些变化。
我们也一定会在内存中授予locking页面，但不要敬畏，因为这些都是64位的盒子。
在我们的例子中，我们自动调整内存（基于脚本），并基于内存消耗阈值，我们已经为所有的情况。 这样内存使用得当。