【问题标题】:Understanding Heap graph from visualvm从 visualvm 理解堆图
【发布时间】:2017-11-21 10:05:11
【问题描述】:

我有一个程序,它基本上从磁盘读取许多文件(混合 PDF 通常低于 10 MB + XML 大小 Kb),然后一次将它们上传到旧系统中。周末去的时候我让它在visualvm下运行,今天早上我回到一个图表,显示在程序运行的小时内堆使用情况相当不均匀。随着时间的推移,我预计堆使用量大致相同。

我正在寻找对此的解释。这是在 Ubuntu 17.04(桌面,而不是服务器)下使用 64 位 Oracle JVM,在 4 核 i5-2400(无超线程)上具有 32 GB RAM。该程序本质上是单线程的,使用了大约 50% 的内核,并且需要预期的时间来运行。

我了解,如果内存未完全使用,它会随着时间的推移而释放。我不明白使用量会随着时间的推移而下降,因为负载应该非常均匀分布。由于系统处于空闲状态,我是否看到了 CPU 节流的结果?是否有一些 JVM 优化启动?

【问题讨论】:

    标签: java garbage-collection jvm heap-memory visualvm


    【解决方案1】:

    实际的 GC 日志会更有帮助,但可能只是 GC 启发式调整他们关于新旧堆大小的决定以满足吞吐量和暂停时间目标。

    只要您不对 JVM 设置限制,它就会很乐意使用比最低限度更多的内存来保持程序运行。如果没有,您将遇到非常频繁且低效的 GC。换句话说,heap size = n * live object set size with n > 1。根据所使用的收集器,除了可用内存之外,n 可能没有上限,因为ParallelGC 默认MaxHeapFreeRatio 为 100,而 G1 使用 70。

    启发式方法远非完美,它们可能会在某些边缘情况下将自己描绘成一个角落,或者在不同的平衡点之间不必要地波动。但图表本身并不表示问题。

    【讨论】:

    • 我不认为这是个问题。我正在尝试了解事物 通常 的外观(以及为什么)能够识别它们何时看起来不再正常。这是使用 JVM 的所有默认值。如果它有任何有用的东西,我可以在以后的运行中启用 gc 日志记录。你有讨论这些 GC 启发式的好资源的链接吗?
    • garbage-collection 标签wiki 有一些资源的链接
    猜你喜欢
    • 1970-01-01
    • 2021-01-02
    • 1970-01-01
    • 1970-01-01
    • 2017-10-31
    • 1970-01-01
    • 2015-03-22
    • 1970-01-01
    • 2018-06-30
    相关资源
    最近更新 更多