我思考由于内存不足和交换导致速度变慢。我查看了资源监视器中的硬故障/秒，它经常超过 1000。这通常是在重新编译期间出现的问题，但当我的源代码编辑器执行一些密集操作时也会出现。
但 1000 只是一个绝对数字，我不确定这是否是我的问题。SSD 驱动器具有快速随机访问功能，因此 1000 可能就足够了。
如果我理解正确的话，当程序访问主内存中没有的内容时，它会发生页面错误，并从磁盘中检索该页面。
然后它可能会把控制权交给另一个进程。
因此从理论上讲，如果有其他进程准备运行，则可能会出现大量页面错误，而不会显著影响吞吐量。
所以我真正想知道的是，处理器空闲但至少有一个进程在等待交换的 CPU 时间百分比是多少？
有什么方法可以得出这个数字吗？我认为这个数字可以很好地说明 RAM 升级能带来多大帮助。或者，有没有其他方法可以测量这个数字，比每秒页面错误数更有参考价值？
答案1
事实上 1000 只是一个绝对数字
如果对于速度较慢的磁盘，Pages Input/sec 计数器显示的值等于或大于 20，和/或对于速度较慢的磁盘，Pages/sec 计数器持续显示每秒输入的页数超过 40 页，或者对于速度较快的磁盘，Pages/sec 计数器持续显示每秒输入的页数超过 300 页，则只需向服务器添加更多内存即可解决此问题。
但 1000 次硬故障/秒大约相当于每秒 4MB 的流量，IO 速率约为 1000每秒输入/输出次数由于 SSD 的额定速度通常为 50000 IOPS（高端驱动器的额定速度甚至为数百万 IOPS），在我看来，在现代系统上进行短时间编译时，这应该不是问题
因此，我们建议您监控与这些计数器相关的承载页面文件的逻辑磁盘的磁盘性能。请注意，每秒持续发生 100 次硬页面错误的系统每秒会经历 400 KB 的磁盘传输。大多数 7,200 RPM 磁盘驱动器在 IO 大小为 16 KB 时每秒可以处理大约 5 MB 的数据，或在 IO 大小为 4 KB 时每秒可以处理 800 KB 的数据。没有性能计数器直接测量硬页面错误解决的是哪个逻辑磁盘。
您实际上不需要知道分页花费了多少时间，但应该通过检查性能监视器（用于检查每秒硬故障数的同一应用程序）中的Physical Disk\%Disk Time和来检查磁盘是否已饱和 IO Physical Disk\Avg Disk Queue Length。如果不是，或者磁盘活跃时间很低，那么可能没问题。你还应该监视Paging File\%Usage页面文件的使用情况，如果太多，那么你确实需要更多 RAM
然而，最可靠的方法可能是检查内核时间在任务管理器中。您可能需要右键单击并检查显示内核时间查看它。在旧版任务管理器中，它是红色部分，而现在则是黑色区域。如果内核占用了很高的 CPU 使用率，那么这是一个真正的问题。这些内核时间可能是由于读取/写入页面文件或内核空间中的任何其他内容花费了太多时间
