是否可以监控“Full GC”? JMX 中的频率(在 HotSpot 上)?

发布于 2024-10-11 03:58:12 字数 399 浏览 9 评论 0原文

我想监控 JMX 中的 Full GC 频率。 MBean 公开 GC 计数。 (参见 http://download. oracle.com/javase/1.5.0/docs/api/java/lang/management/GarbageCollectorMXBean.html - java.lang:type=GarbageCollector,name=)。

问题是MBean 不区分minor GC 和full gc。

有人有主意吗?

谢谢。

阿尔诺

I want to monitor Full GC frequency in JMX. A MBean exposes GC count.
(cf. http://download.oracle.com/javase/1.5.0/docs/api/java/lang/management/GarbageCollectorMXBean.html - java.lang:type=GarbageCollector,name=).

The problem is that MBean does not distinguish between minor and full gc.

Does someone have an idea ?

Thanks.

Arnault

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

╰つ倒转 2024-10-18 03:58:12

我对此并不完全确定,但我假设控制所有内存池(至少是老一代的内存池)的垃圾收集器是用于主要GC的垃圾收集器。例如:我有一个 JVM 与这 2 个收集器一起运行:

  • PS MarkSweep
    • MemoryPoolNames:PS Eden Space、PS Survivor Space、PS Old Gen、PS Perm Gen
    • 集合计数:68
    • 内存

  • PS Scavenge
    • MemoryPoolNames:PS Eden Space、PS Survivor Space
    • 收藏数量:2690

考虑到这一点我想说,PS Scavenge 用于minor gc,PS MarkSweep 用于major gc。

更新(基于 @ajeanson 评论,顺便说一句,感谢您的反馈):

实际上,我放在那里的示例取自我正在使用的 JVM 的 MXBeans 中公开的信息。正如您所提到的,这些是 GC 算法,GC 的 MXBean 使用的名称基于 GC 使用的算法。我一直在寻找有关此的更多信息;在本文中 http://download.oracle.com/ javase/6/docs/technotes/guides/management/jconsole.html,内容如下:

Java HotSpot VM 定义了两个
世代:年轻一代
(有时称为“托儿所”)和
老一代。年轻人
一代由“伊甸园空间”组成
和两个“幸存者空间”。虚拟机
最初将所有对象分配给
伊甸园空间,大多数物体都会死亡
那里。当它执行minor GC时,
VM 移动所有剩余对象
从伊甸园空间到其中之一
幸存者空间。 VM移动对象
在幸存者体内活得足够长
空间到“终身”空间
老一辈。当终身教职时
一代已满,有一个完整的
GC 通常要慢得多,因为
它涉及所有有生命的物体。这
永久代拥有所有
虚拟机的反射数据
本身,例如类和方法
对象。

看一下 MXBean 上的 collectionCount 属性,在我的“PS MarkSweep”收集器(管理老一代池的收集器)的情况下,收集计数似乎仅当我在详细输出中获得完整 GC 时才会增加。我可能是错的,也许在某些情况下这个收集器也执行小型 GC,但我需要运行更多测试才能完全确定这一点。
如果有人发现了其他问题,或者您有关于此问题的更多具体信息,请告诉我,因为我对此非常感兴趣。

I'm not completely sure about this but I assume that the garbage collector that controls all the memory pools (at least the one for Old Gen) is the one used for major gc. e.g.: I have a JVM running with these 2 collectors:

  • PS MarkSweep
    • MemoryPoolNames: PS Eden Space, PS Survivor Space, PS Old Gen, PS Perm Gen
    • CollectionCount: 68
  • PS Scavenge
    • MemoryPoolNames: PS Eden Space, PS Survivor Space
    • CollectionCount: 2690

Taking this into account I would say, PS Scavenge is used for minor gc and PS MarkSweep for major gc.

UPDATE (based on @ajeanson comment, thanks for your feedback btw):

Effectively, the example I put in there was taken from the information exposed in the MXBeans of the JVM I was using. As you mentioned, these are GC algorithms, and the name the MXBean for the GC is using is based on the algorithm the GC is using. I've been looking for some more information about this; in this article http://download.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html, reads the following:

The Java HotSpot VM defines two
generations: the young generation
(sometimes called the "nursery") and
the old generation. The young
generation consists of an "Eden space"
and two "survivor spaces." The VM
initially assigns all objects to the
Eden space, and most objects die
there. When it performs a minor GC,
the VM moves any remaining objects
from the Eden space to one of the
survivor spaces. The VM moves objects
that live long enough in the survivor
spaces to the "tenured" space in the
old generation. When the tenured
generation fills up, there is a full
GC that is often much slower because
it involves all live objects. The
permanent generation holds all the
reflective data of the virtual machine
itself, such as class and method
objects.

Taking a look at the collectionCount property on the MXBeans, in the case of my "PS MarkSweep" collector (the one managing the Old Generation pool), the collection count seems to increase only when I get a full GC in the verbose output. I might be wrong and maybe in some cases this Collector performs also minor GC, but I would need to run more tests to be totally sure about this.
Please, let me know if someone finds out something else or you have some more specific information about this issue as I'm quite interested in it.

神仙妹妹 2024-10-18 03:58:12

它确实...看看名称,例如 ParNew、ConcurrentMarkSweep 等。
有些名称用于minor gc,有些用于full gc,

it does ... have a look to the names e.g. ParNew, ConcurrentMarkSweep, .. etc.
some names are for minor gc, some for full gc,

我恋#小黄人 2024-10-18 03:58:12

正在寻找相同的信息,并在阅读 https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html#BABFAFAE 对于 JAVA 8,某些收集器可用于 Minor/Full GC(例如G1 或 SerialGC),但其他一些收集器仅用于次要或完整 GC(例如 ParNewGC、ConcMarkSweepGC)。

例如,当您使用 G1 时,所使用的两个收集器的名称非常明确,用于完整 gc 的收集器是 G1 老一代。

但是,因为 MXBean 缺少有关次要或完整的信息,要么:

  • 您知道应用程序使用的 GC 并相应地编码,您的监控方法知道收集器名称
  • ,或者您开始​​拥有所选 JVM 的所有可能性的地图 就我而言

,我将只打印收集器名称以及时间和计数值,然后让读取这些数据的人进行分析。就我而言,数据将被绘制成图表(Grafana)

不确定最新的 JDK 是否改进了这一点......

Was looking for the same information and found out after reading https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html#BABFAFAE for JAVA 8 that some collectors can be used for both minor/full GCs (such as G1 or SerialGC) but some other collectors are for only minor or full GCs (such as ParNewGC, ConcMarkSweepGC).

And when you use the G1 for example, the two collectors used are quite explicit with their names and the one for full gc is the G1 Old Generation.

But, because the MXBean is missing the information about being minor or full, either:

  • you know the GC in use for your app and code accordingly your monitoring method knowing the collector names
  • or you start having like a map of all possibilities for your selected JVM version

I will, in my case, just print the collector name along with the time and count value and let the person reading those data make the analysis. In my case, the data will be graphed (Grafana)

Not sure if the newest JDK improve this...

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文