SQL Server 随着时间的推移变得越来越慢，直到我们必须重新启动它

Question

我们有一个混合 OLAP/OLTP 工作负载的数据库。查询是非常临时的，并且是在中间层应用服务器中动态创建的。当我们启动服务器时，性能还算可以接受，但是内存消耗会越来越多，直到所有可用内存（30GB）耗尽。之后，系统变得越来越慢。

命令之类的Dbcc freeproccache无效。

没有多少交易select * from sys.dm_tran_session_transactions（不超过系统正常时），有时这个列表是空的。

第一个结果dbcc memorystatus是

VM Reserved               42136628
VM Committed               1487176
Locked Pages Allocated    24994048
Reserved Memory               1024
Reserved Memory In Use           0

重新启动 SQL Server 可以暂时解决问题。

1. 是什么导致了这种行为？如何避免？
2. 如果真正解决原因太困难，是否有命令强制 SQL Server 实际释放所有内存而无需完全重启 DBMS？

服务器在专用硬件（不是虚拟机）上运行。我们有一些预定的工作，但我们暂时禁用了它们，没有任何变化。在同一台服务器上还有其他中层应用程序运行，但它们使用的内存不超过 2GB，CPU 可以忽略不计，并且几乎没有 I/O。我们重新启动了所有此类应用程序，没有任何更改。

Answer 1

我建议在此服务器上收集性能指标，这样您就可以消除对这些类型问题进行故障排除的猜测。如果您不知道从哪里开始，请参阅这篇文章以获取更完整的指南。

特别是，我会检查性能计数器Memory\Available MBytes，Paging File(_Total)\% Usage因为您说问题仅在缓冲池已满时才开始发生。您从这些计数器获得的数字可能表明需要针对分配给服务器的物理内存量调整（向上或向下）最大服务器内存设置。正如我在这里提到的，我不建议将最大内存设置基于物理内存量，除非作为对起点的有根据的猜测。始终衡量结果，并从那里进行调整。

如果可用内存量太低 (< 500)，或者页面文件使用量超过零，这可能表明 SQL Server 实例被过度使用：在 SQL Server 2008 R2 上，最大服务器内存设置仅控制缓冲池大小，而不是其他内存使用，例如计划缓存。SQL Server 也不关心您可能在系统上运行的其他应用程序。这种额外的内存使用会给 Windows 或其他应用程序带来内存压力，可能会导致磁盘交换。这是您想不惜一切代价避免的事情，特别是如果页面文件存在于仅由简单 RAID 1 镜像支持的卷上时。我的感觉是这就是问题所在，取消最大服务器内存设置应该可以解决问题。

如果可用内存量很高（> 1000）并且页面文件使用量为零，您可能可以稍微提高最大服务器内存（以 256 MB 为增量）以最大化服务器的内存使用量。但是，这很可能无法解决问题，您需要查看其他地方，可能是物理磁盘计数器和缓冲池页面预期寿命。如果查询正在冲击缓冲池，除了提高磁盘性能、增加服务器可用的物理内存量以便所有数据页都可以一次性放入内存中，或者修改数据库以不占用太多内存之外，您无能为力物理空间（可能通过使用行或页压缩，或者通过使用更高的 重建索引FILLFACTOR）。

我已经发表了关于这一主题的文章在这里是进入有关此问题以及如何解决这个问题更深入。