我的问题是,对于具有 TB 级 RAM 的实例,SQL Server 需要很长时间来增加它的内存使用量,同时我们会间歇性地等待 MEMORY_ALLOCATION_EXT,这会减慢我们的处理速度,直到 SQL Server 达到其最大内存。
我们有 SQL Server 2019 企业版的故障转移群集实例 (FCI),节点上有数 TB 的内存。在通常的用例中,我们只允许每个节点有 1 个 SQL Server 实例,因此我们将最大服务器内存设置为接近节点内存的 85%,但我们也将最小服务器内存设置得相对较低,以防 SQL Server 发生故障到另一个节点,并且需要在减少内存占用的情况下联机才能跛行。
有没有其他方法可以强制 SQL Server 快速增加其内存使用量?
SQL Server 不会将内存用于缓冲池(它的最大用途),直到它需要从存储加载页面,因为它们被引用。除非你做了一些奇怪的事情来使内存分配变慢[†]那么你的延迟不太可能是因为读取它正在分配的数据以便保存。我怀疑在那些内存分配等待的同时,你有匹配的 IO 相关等待。
要强制 SQL Server 将内容加载到内存中,从而在可用和需要时分配内存,请访问需要加载的内容。启动 SQL 实例后,运行只读工作负载,以便将应用程序的正常公共工作集加载到缓冲池中。
不要仅仅SELECT * FROM HugeTable
因为这可能会加载一个糟糕的数据平衡(不是应用程序核心工作集)所以核心工作集仍然需要在下次访问时从磁盘/网络加载,所以你将拥有相同的 IO延误。此外,如果HugeTable
真的很大,SQL Server 可能会发现它并不完全适合,并且无论如何都不会在内存中保留大量它[‡]。
[†]在超载主机上的 VM 中运行,所以看起来像真实 RAM 的东西实际上是磁盘页面?!
[‡]在正常情况下,您不希望对大对象进行意外的表/索引扫描以从内存中清除其他所有内容。对一个查询从一个对象中保留多少的限制是一种尝试阻止这种情况发生的优化)。