内存未满时分页文件使用率高

Question

我收到了一台托管 SQL Server 的服务器，我被要求对其性能问题的原因进行罚款。

在监视 PerfMon 时，我发现：

分页文件： % 使用率 = 3 天平均25% 。 内存：页/秒 > 1 平均 3 天。 我所知道的是，如果 % Usage 大于 2%，那么由于内存压力和内存空间不足，分页过多。 但是，如果当我打开资源监视器，内存选项卡时，我发现：

-26 GB 正在使用中（总 RAM 为 32 GB）-2 GB 待机 - 和4 GB 内存可用！！！！！！

如果有 4 GB 空闲内存，为什么要分页？！ 最重要的是为什么它（分页百分比）太高了？！

有人请解释这种情况以及如何将页面文件的使用百分比降低到正常水平。

请注意，SQL Server Max. 内存设置为15GB

Answer 1

页面文件的使用本身并不是一个主要的危险信号。 即使有足够的 RAM 可用，操作系统也会倾向于使用页面文件，因为它允许它在需要时从 RAM 转储内存的相关部分 - 不要将页面文件的使用视为内存从 RAM移动到 HDD -这只是一个副本。 所有访问仍将使用 RAM，操作系统只是在为意外情况做准备 - 如果它没有将内存预先写入页面文件，则内存请求将不得不等待“旧”内存在释放之前被转储RAM 用于其他用途。

此外，您似乎对分页的工作方式有些困惑。 所有用户空间内存总是被分页，这与页面文件本身无关 - 它只是意味着您正在使用虚拟内存。 您正在寻找的指标是每秒硬故障数（编辑：呃，我误读了您正在阅读的内容 - 页数/秒是有多少硬故障；不过，其余的仍然适用），它告诉您发生的频率操作系统必须实际从页面文件中读取数据。 即便如此，每秒 1 次也非常低。 在该数字超过每秒 50 次之前，您几乎看不到任何东西，而对于 SSD 而言则要高得多（在我的特定系统上，我可能会遇到数千个硬故障而没有明显的内存延迟 - 这会因实际硬盘驱动器和您的芯片组和驱动程序）。

最后，SQL Server 性能受到影响的方式太多了。 如果您没有真正的 DBA（或者至少是具有丰富 DB 经验的人），那么您就有麻烦了。 您的大多数查询行都会将您引向死胡同 - 像数据库引擎一样复杂和优化的东西总是很难正确诊断。 识别迹象 - 是否存在高 CPU 使用率？ RAM使用率高吗？ 是否存在 I/O 使用率高的查询？ 是否有特定查询给您带来麻烦，或者整个数据库是否受到影响？ 您的索引和表格是否得到妥善维护？ 这些只是最基本的。 一旦你有一些像这样的额外信息，试试DBA.StackExchange.com - SO 并不是寻求 DBA 建议的正确地方:)

Answer 2

真的只是在黑暗中拍摄一些照片，可能有点随机，但我几乎无法立即发现：

• 是否有进程会选择无用的大数据集或运行过于频繁的操作？ （例如，糟糕的应用程序开发人员的做法是在任何地方使用SELECT *或获取所有数据，然后在应用程序级别对其进行过滤或在循环中运行数据库查询而不是获取一次记录集等）
• 索引正确吗？ （例如，尽可能减少关键查找操作的叶元素，是否使用适当的索引备份大量查询以避免表和索引扫描等）
• 如何管理数据群？ （例如，是否可能由于不正确的聚集索引或并行插入而导致页面拆分过多，是否发生了一些索引重建等）