它是 Window 2003 服务器。
我们正在运行一些性能测试,我们看到的是:
在前 5 小时内,page fault/sec 非常小,例如 10 或 20
在过去 1 小时内,缺页率跃升至 500 次缺页/秒
在过去的 1 小时内,我们看到了很多 full GC。
注意,我们有足够的内存,比如 64G,整个系统只使用了一半,所以应该不会有很多硬页错误。
我想知道的是,当 JVM 进行 GC 时,与没有 GC 相比,预计会看到大量的软页面错误/秒吗?
它是 Window 2003 服务器。
我们正在运行一些性能测试,我们看到的是:
在前 5 小时内,page fault/sec 非常小,例如 10 或 20
在过去 1 小时内,缺页率跃升至 500 次缺页/秒
在过去的 1 小时内,我们看到了很多 full GC。
注意,我们有足够的内存,比如 64G,整个系统只使用了一半,所以应该不会有很多硬页错误。
我想知道的是,当 JVM 进行 GC 时,与没有 GC 相比,预计会看到大量的软页面错误/秒吗?
增量垃圾收集器将它们的执行与mutator交错。这可能会导致两种问题:
mutator 可能会更改垃圾收集器已经分析过的对象(例如,更新引用)。在这种情况下,需要通知收集器有关更改,以便它可以考虑更改。
在复制收集器的情况下,mutator 可能想要查看收集器已移动的对象。在这种情况下,需要通知收集器尝试从移动的对象中读取,以便可以将 mutator 重定向到对象的新副本。(使用存储在“破碎的心”中的转发指针。)
问题 (1) 可以通过收集器在已完成分析的页面上放置硬件写入屏障来解决。问题 (2) 可以通过收集器在包含已移动对象的页面上放置硬件读取屏障来解决。
当 mutator 遇到这些障碍时,就会产生页面错误,并且错误处理程序从垃圾收集器运行适当的函数。
(我不确定这是否是 JVM 垃圾收集器在 Windows 上的工作方式,但在增量垃圾收集期间预计会增加页面错误。)