Dre*_*ert 10 sql-server memory windows-server sql-server-2017
我在 Windows Server 2012 R2 上运行 SQL Server 2017，并将内存从 256 GB 增加到 512 GB。我注意到虚拟内存的以下配置：
有很多关于将大小设置为已安装内存大小的 1.5 或 2 倍的建议。我读得对还是我误读了这些文章并且它们适用于其他东西？
也有文章建议不要担心虚拟内存，因为SQL应该只使用RAM而不是虚拟内存，而操作系统只需要2GB的虚拟内存？
Ton*_*kle 22
我认为 2 倍大小的 RAM 建议已经过时且不切实际。如果服务器只有 32 GB 的 RAM，这可能是有道理的，但在具有大量内存的系统上使其 2 倍是浪费昂贵的磁盘空间。
页面文件有两个主要用途：
用作内存的交换文件。 如果正确配置 SQL Server 和其他应用程序以限制可用内存量，则永远不需要用于此目的。如果系统确实必须使用页面文件来交换内存，那么系统性能将非常糟糕，您实际上会出现中断并被迫立即处理。因此，如果您配置一个 1 TB 的页面文件，那么当系统开始交换到磁盘时它对性能没有帮助，并且您将被迫在它需要交换 100 GB 之前对其进行一些处理。
在系统崩溃时保存内存转储（在安装操作系统的卷上）。同样，如果服务器只有 32 GB 的 RAM，则将其配置为在系统崩溃时执行完整内存转储是有意义的。但是，出于诊断目的很少需要完整内存转储，并且内核内存转储是具有大量内存的系统的合理选择。此外，与 1996 年（或任何时候）提出 2 倍建议时相比，如今 Windows 崩溃的频率要低得多。此外，如果系统崩溃并且您获得 1 TB 内存转储（您需要在 c: 上提供另一个 TB 可用空间），祝您好运，压缩该垃圾并将其转移到 Microsoft。我只会配置内核转储，并且仅在系统崩溃并且 Microsoft 需要完整内存转储来诊断问题时才更改它。
因此，如果您是超级偏执狂（在某些情况下这当然是合理的）并且有 2 TB 的分配可能永远不会使用，那么一个巨大的页面文件是一个考虑因素。然而，这很少是真正必要的。
所以我的回答是你不太可能需要增加页面文件的大小。它可能没有以当前大小使用，而且现在有更多的内存，它更不可能被使用，因此因此无需在更大的磁盘上浪费更多的磁盘空间。
这在如何确定 64 位版本的 Windows 的适当页面文件大小中有非常明确的说明
崩溃转储设置
如果您希望在系统崩溃期间创建故障转储文件，页面文件或专用转储文件必须存在并且足够大以备份系统故障转储设置。否则，不会创建系统内存转储文件。
有关更多信息，请参阅支持系统故障转储部分。
高峰系统提交费用
系统提交费用不能超过系统提交限制。此限制是物理内存 (RAM) 和所有页面文件的总和。如果不存在页面文件，则系统提交限制略小于安装的物理内存。系统提交的峰值内存使用量可能因系统而异。因此，物理内存和页面文件大小也有所不同。
因此，除非您正在对崩溃进行故障排除，否则您可以调整页面文件的大小以适应“峰值系统提交费用”。这是在 Windows 中分配的最大虚拟内存总量。您的 RAM + 页面文件大小应略大于观察或预测的峰值系统提交费用。
当系统内存不足时，SQL Server 会自动减少其内存使用量。请参阅内存管理架构指南。因此，对于专用 SQL Server，页面文件的使用相对较少。由于 SQL Server 将其内存使用量保持在服务器 RAM 量以下，峰值系统提交费用应该只有几 GB，因为在服务器上运行的其他进程提交虚拟内存。
因此，对于 SQL Server 而言，8GB 或 16GB 通常是足够的页面文件大小。这还没有设置 Max Server Memory 来限制 SQL Server 的 RAM 利用率。
如果 SQL Server 以 100% 的利用率运行，您需要足够的 RAM + 页面文件来运行辅助进程，如 SQL 代理作业、SSIS 包，甚至服务器上的资源管理器和 SSMS 以进行故障排除。