为什么需要定期重启才能保持实例正常运行？

我们已经在SQL 2005上提供了一个生产数据库服务器。一切正常运行了一段时间，但是几周后，我们发现性能明显下降。仅重新启动SQL Server才能使性能恢复正常。

一些背景：

• 运行1200多个数据库（大多数是单租户，一些是多租户）。在任何人只讲讲多租户讲座之前，有充分的理由保持这种结构……
• RAM是16 GB。重新启动后，SQL Server很快就可以恢复到15 GB的使用率。
• 活动的数据库连接大约有80个连接-考虑到每个进程每个Web服务器有一个连接池，我们认为这很健康-因此我们没有连接泄漏问题。

我们在非高峰时间尝试了几种方法：-运行DBCC DROPCLEANBUFFERS（带有CHECKPOINT）以清除数据缓存。它无效，也不会清除任何RAM使用情况。-运行FREEPROCCACHE和FREESYSTEMCACHE清除查询计划和存储的proc缓存。没有效果。

显然，在活动的生产环境中重新启动SQL Server是不理想的。我们缺少了一些东西。还有其他人经历吗？

更新：2012年4月28日 仍在解决此问题。我已将SQL Server的内存降低到10 GB，只是为了排除与操作系统的争用。我正在接近缩小范围，但是下一步需要一些帮助。

这是我发现的，重新启动SQL Server之后，页面文件在12.3 GB和12.5 GB之间徘徊。它将保持这种状态数天。服务器线程总数将介于850和930之间-连续几天也稳定且一致（sqlserver取决于流量，稳定在55和85之间）。

然后，有一个“事件”。我不知道事件是什么，我无法在日志中看到它，并且在事件发生的一周中的任何一天或时间都看不到任何一致的信息，但是突然之间，他的页面文件跳到了14.1或14.2。 GB，并且线程数跳到1750和1785之间。

在发生这种情况时检查perfom，其中有900多个线程是sqlserver。所以我去sp_who2看看这些线程是从哪里来的...而且只有大约80个使用过的数据库连接。

所以....有谁知道我如何找到SQL Server上这900个线程的其余位置以及它们在做什么？

更新：2012年6月1日 仍在与问题作斗争。对于仍然阅读此书的人来说，线程跳转的问题已得到解决。这是由自动的ComVault备份软件引起的。它正在创建一个线程，尝试备份不再存在的数据库（它正在维护以前的数据库列表），而不是仅备份当前数据库。

但是-问题仍然存在，我们必须每周重新启动，花几天时间。与Rackspace团队合作，看看他们是否可以阐明任何想法。

您说一切都很好，然后在几周后性能下降。（通常，人们声称性能会迅速下降，或在特定时间或以随机间隔出现。这可能意味着I / O性能下降，锁定风暴或在更糟糕的时间运行CPU密集型查询，或者计划任务繁重或缺乏索引编制或错误的统计信息会导致CPU密集型查询或磁盘读取等操作。

我的假设是服务器上的另一个应用程序正在泄漏内存。我已经通过病毒软件（每个DBA最喜欢的服务器软件反派）和第三方监控软件看到了这一点。随着时间的推移，我将仔细检查SQL Server的内存使用情况，然后我还将获取包装盒上所有其他应用程序的所有内存使用情况。如果您对SQL Server的内存使用量设置了硬性限制，并且将其设置为不允许分页，则可能是其他应用程序正在被分页并占用I / O容量。

不难寻找。如果您尚未在服务器上保留指标，那么我将启动Perfmon并让它每30或60分钟获取一次样本。几天后，您可能会看到其他应用程序的内存使用率上升。

SQL Server日志中是否有错误消息指出“ SQL Server的重要部分已被调出”？那也是一个大提示。

让我祝贺您能够在只有16 GB RAM的单个SQL Server实例上运行1200个DB，并且在顺利运行了几周后才遇到这些类型的问题。在当地的“通行证”一章讲的好故事。

现在进行故障排除：SQL和OS的RAM为16 GB。我假设您的最大内存设置为15 GB或最大。这可能会导致缓冲池用完所有内存并阻塞操作系统。您是说清除缓冲池和缓存没有任何区别，而且您的PLE大于300。这证明存在内存瓶颈。服务器上的CPU和IO情况如何（规格/统计）？

运行select * from sys.dm_exec_request where session_id>50 and session_id<>@@spid以及您看到的资源争用是什么（wait_type，wait_time，last_wait_type，wait_resource）。

1200个数据库，一个OS以及其他可能的东西？是的，我认为服务器本身需要超过1gb的ram才能运行，特别是考虑到，如果将15gb设置为SQL Server的最大内存设置，则它仍需要15gb之外的线程额外内存。

我会将SQL Server降低到14gb，以便为服务器提供更多的喘息空间。

另外，“ SQL Server 2008内部和故障排除”中给出了一个示例，该示例使用带有16GB RAM的第三方备份实用程序的SQL Server 2008 x64系统上的内存余量：

• Windows 2 GB
• 1GB用于工作线程
• 1GB用于MPA等
• 1GB用于备份程序
• SQL Server 11GB

在书中，它显示了如何确定可以拥有的最大线程数，以及如何计算它们将占用多少内存。运行此命令（更改服务器类型以匹配您的服务器）以找出线程将需要多少内存。

declare @servertype int

set @servertype=1
/*
1: x86 (32-bit)
2: x64 (64-bit)
3: IA64

*/

select max_workers_count *
    (
        case @servertype when 1 then .5
            when 2 then 2
            when 3 then 4
            else .5
        end
    )
from sys.dm_os_sys_info

如果数据库内存均匀分布在所有数据库中，则每个数据库只有12.8 Meg（15 * 1024）/1200=12.8。您需要更多的内存。

您需要研究性能下降的原因。您是否看到锁定，阻塞等？等待状态看起来如何？

DBCC命令只会清除内存缓冲区，而不会将内存释放回OS。

您知道SQL Server实际上正在消耗内存吗？我建议您考虑设置Perfmon会话，或者在重新启动后开始收集DMV信息，以了解SQL Server在做什么和在做什么。还请注意，如果用户在您的收集时间内没有完成比平时更多的工作（例如月末处理等）。您是否在同一服务器上运行SSRS，SSIS或SSAS？

您的系统上有1200个数据库，最大的DB是多少？