SQL Server 实例如何恢复使用的内存

Question

我知道这个问题可能已经回答了很多次了，但我需要一个更好的方法来解决它，或者向我的老板证明这是一种正常行为，或者我忽略了一些东西。

我不是 DBA，我是一名开发人员，就像我以前的工作一样，我必须担任 DBA Mantle，因为我们现场没有正式的 DBA，或者没有人想认真对待这件事。

我有三个 SQL Server 实例，一个使用 SQL 2008 R2，两个使用 SQL 2016。全部来自生产环境。

SQL 2008 R2 来自我们的主系统，它托管在 Hyper-V 中的虚拟服务器中，并且是专用数据库服务器。该服务器上没有分配其他应用程序，它是一个纯数据库服务器。

问题是服务器配置了 30 GB 的 RAM，而 SQL Server 配置为使用从最小 4 GB 到最大 22 GB。

如果我重新启动，显然服务器内存使用量在服务器性能管理器上趋于平缓，从使用的内存中释放内存到配置的最小值。

我需要帮助理解这种情况，因为所有文档都指向一个无可辩驳的事实，即这在 SQL Server 中是正常的，我已经对此进行了记录，但是我的老板和同事表示这不是数据库的正常行为。如果我做数字，我认为服务器正在请求更多内存。他们说这不是 SQL Server 的正常行为，而且我们忽略了一些东西（工作和其他东西）。为了监控或尝试确定服务器行为，我开始每两个小时发送一次数据库健康报告，以尝试检查发生了什么。对于他们来说，预期的行为是 SQL Server RAM 应该在性能图中上升和下降，而不是一直保持在顶部，据我了解，这是预期行为或 SQL Server 的设计。

但是在不同的时间点，作业上升到执行，并且它们正常完成，一些长时间运行的事务正在运行，但是当我在生成报告后为它们运行查询时，它们消失了。

有什么我忽略的吗？这是正常的吗？有没有办法在不重启实例的情况下释放内存？我已经尝试了很多解决方案

Answer 1

这是正常的吗？

是的。

我的老板和同事说这不是数据库的正常行为

SQL Server 将根据您的配置增加其内存使用量，max server memory并且仅在系统物理内存不足时才减少其内存使用量。

如果系统有足够的可用 RAM，SQL Server 将使用它来缓存数据和执行计划，并有可用的内存来运行查询。

如果 Windows 发出全局“内存不足”信号，SQL Server 将通过调整其缓存和取消分配内存来响应。

这在文档中有详细解释：

SQL Server 数据库引擎的默认内存管理行为是获取所需的尽可能多的内存，而不会造成系统内存不足。SQL Server 数据库引擎通过使用 Microsoft Windows 中的内存通知 API 来完成此操作。

当 SQL Server 动态使用内存时，它会定期查询系统以确定可用内存量。维护此空闲内存可防止操作系统 (OS) 进行分页。如果可用内存较少，SQL Server 将向操作系统释放内存。如果有更多内存可用，SQL Server 可能会分配更多内存。SQL Server 仅在其工作负载需要更多内存时才添加内存；静止的服务器不会增加其虚拟地址空间的大小。

最大服务器内存控制 SQL Server 内存分配、编译内存、所有缓存（包括缓冲池）、查询执行内存授予、锁管理器内存和 CLR1 内存（基本上是在 sys.dm_os_memory_clerks 中找到的任何内存管理员）。

内存管理架构指南 - 动态内存管理

有没有办法在不重启实例的情况下释放内存？

您可以减少最大服务器内存，SQL Server 将修剪其缓存并在线减少其内存使用量。下降后，您可以max server memory再次增加缓存，SQL Server 将随着时间的推移重新增长缓存。

但这个过程在操作上毫无意义。其他任何事情都不需要内存，如果需要，SQL Server 将通过降低其内存利用率来响应系统内存不足信号。

Answer 2

您可以找到最权威的答案，以及 David Browne 的答案。你现在可以回到你的同事那里说“嘿，我和微软的某个人谈过，答案是这完全是 SQL Server 设计的正常行为。我认为我们中没有人比创建 / 的人更了解 /自己维护产品。 ”（如果你正在和你的老板谈话，也许可以把最后一部分去掉。:)如果微软员工的口口相传不够好，你可以向他们展示产品中的正确性监控内存使用情况 - 配置 SQL Server 最大内存中的文档：

默认情况下，SQL Server 实例可能会随着时间的推移消耗服务器中大部分可用的 Windows 操作系统内存。一旦获得内存，除非检测到内存压力，否则不会释放。这是设计使然，并不表示 SQL Server 进程中存在内存泄漏。

但我想补充几件重要的事情：你的同事这样认为的原因是因为他们在正常的服务器环境中是正确的，该环境旨在处理多个应用程序，其中共享很重要，并且资源峰值保持时间过长可能是一个问题例如，存在严重内存泄漏问题的应用程序的迹象。

在服务器环境中，该服务器旨在尽可能为一个应用程序（在这种情况下为SQL Server）执行最佳性能，那么只有允许该应用程序尽可能多的可用资源才有意义（在合理范围内，操作系统需要一点资源本身），以便应用程序 ( SQL Server ) 可以尽可能高效地运行。

正如大卫在他的回答中提到的，特别是在内存方面，SQL Server缓存了很多东西。但是它缓存的最重要的事情之一是表数据的数据页，这样当运行重复查询需要访问这些页中的任何数据时，它可以直接从内存而不是性能较低的磁盘中获取. 想象一下，如果每次运行查询时总是需要从磁盘获取所有数据，尤其是在谈论数百万行/千兆字节的数据时。这对任何人来说都不是一个有趣的时间。

SQL Server 也以其他方式表现出这种行为，例如，当数据库文件（事务日志和数据文件）增长时，它们如何保留一定数量的额外磁盘空间（基于配置的数据库选项）。虽然额外的磁盘空间实际上并没有被SQL Server主动使用，但这样做可以让它在需要时更有效地运行（内部数据以较慢的速度增长），而不是不断地从磁盘请求空间，这将是次要的。它还保证SQL Server将拥有其增长所需的空间。

最后，我要说明的最后一点是，重新启动服务器或SQL Server 实例实际上会适得其反。通过清除内存中的所有缓存对象，您的SQL Server在重建缓存的第一天左右可能会运行得更慢，并且您可能会因此看到更多的性能问题，而不是离开它是并让SQL Server做它设计要做的事情。

长话短说，在唯一目的是支持一个应用程序（在本例中为SQL Server）的环境中，将大部分资源分配给该应用程序以使其尽可能高效地运行是正常的。否则，如果资源被闲置而不被使用，它们就是一种浪费（在物质上和金钱上）。