随着时间的流逝，SQL Server变得越来越慢，直到我们不得不重新启动它为止

我们有一个混合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的情况下实际释放所有内存？

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

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

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

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

如果可用内存量很高（> 1000），并且页面文件使用率为零，则可能会稍微增加最大服务器内存（以256 MB为增量），以最大程度地利用服务器的内存。但是，这很可能无法解决问题，您需要将目光转向物理磁盘计数器和缓冲池页面预期寿命。如果查询影响了缓冲池，则除了提高磁盘性能，增加服务器可用的物理内存量，使所有数据页可立即放入内存或修改数据库以使其不占用太多内存外，您无能为力物理空间（可能通过使用行或页面压缩，或者通过使用更高的索引来重建FILLFACTOR）。

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

通常，随着时间的流逝，缓慢的趋势应该是相反的，因为随着数据库页面移入缓存，性能应该提高（页面寿命预期和缓冲区命中率随时间增加），您是否将最大内存设置为（total_physical_mem-2GB）？

听起来您的几个查询正在导致SQL Server分页和分页很多内容。您可以尝试使用资源调控器来限制大查询和中查询的内存消耗，以便应用程序查询始终具有足够的可用缓冲区。