我收到了一台托管SQL Server的服务器，我被要求对其性能问题的原因进行罚款。
在监控PerfMon时我发现：
分页文件：％Usage = 25％平均3天。 记忆：页数/秒＆gt;平均3天。 我知道如果％Usage是＆gt; 2％因为内存压力和内存空间不足而导致分页过多。但是，如果我打开资源监视器，内存选项卡，我发现：
-26 GB正在使用中（总共32 GB内存） -2 GB待机 - 并且 4 GB无内存 !!!!!!
如果有4 GB可用内存为什么分页？！最重要的是为什么它（分页％）太高了？!!
请有人解释一下这种情况以及如何将分页文件％的使用率降低到正常水平。
请注意SQL Server Max。内存设置为15GB
答案 0 :(得分：1)
页面文件的使用本身并不是一个重要的红旗。即使有足够的RAM可用，操作系统也倾向于使用页面文件，因为它允许它在需要时从RAM中转储相关的内存部分 - 不要将页面文件用作内存将从RAM移动到HDD - 它只是一个副本。所有访问仍将使用RAM，操作系统只是为应急做准备 - 如果它没有预先写入页面文件的内存，内存请求将不得不等待＃34;旧＆＃34 ;在释放RAM以供其他用途之前要转储的内存。
此外，您似乎对分页的工作方式感到有些困惑。所有用户空间内存总是分页，这与页面文件本身无关 - 它只是意味着您正在使用虚拟内存。您正在寻找的指标是每秒硬故障（编辑：呃，我误读了您正在阅读的那个 - Pages / sec 是多少存在硬故障;其余仍然适用），它告诉您操作系统实际上从页面文件中实际读取数据的频率。即便如此，每秒1次极低。你很少会看到任何东西，直到这个数字超过每秒50左右，并且SSD更高（在我的特定系统上，我可以获得数以千计的硬故障而没有明显的内存延迟 - 这根据实际的硬盘驱动器而变化很大你的芯片组和驱动程序）。
最后，SQL Server性能可能受到太多影响。如果您没有真正的DBA（或至少有足够数据库经验的人），您就会陷入困境。您的大多数查询行将引导您走向死胡同 - 与数据库引擎一样复杂和优化的东西总是难以正确诊断。识别标志 - CPU使用率是否很高？是否有高RAM使用率？是否存在高I / O使用率的查询？是否有特定的查询给您带来麻烦，或者整个数据库是否受到影响？您的指数和表格是否得到妥善维护？这些只是非常基础。一旦你有了这样的额外信息，试试DBA.StackExchange.com - 这不是要求DBA建议的正确位置：）
答案 1 :(得分：0)
在黑暗中真的只是一些镜头，可能有点随机，但我几乎找不到任何东西：
SELECT *或获取所有数据，然后在应用程序级别过滤它或在循环中运行数据库查询，而不是获取记录集等等。）