小编Pau*_*ulJ的帖子

我们在 SQL 2005 上有一个生产数据库服务器。一切正常运行了一段时间，但几周后我们看到性能显着下降。只有重新启动 SQL Server 才能使性能恢复正常。

一些背景：

• 运行超过 1200 个数据库（主要是单租户，一些是多租户）。在任何人讲到只迁移到多租户之前，保持这种结构是有正当理由的......
• 内存为 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 …