我正在使用Spring Boot 2.2.5,并通过Spring Boot执行器和Grafana监视我的应用程序指标。
我的应用程序与Docker(OpenJdk11)打包在一起,并配置有4GB内存
我的gc暂停时间较长,大约需要1-2秒,并且与 jvm.gc.memory.allocated 相关联。
jvm.gc.memory。分配的指标有时会达到 30GB
有人可以解释 jvm.gc.memory.allocated 指标吗?是什么意思?
答案 0 :(得分:1)
如果您问我,这是一个相当奇怪的指标(从某种意义上来说,掌握起来并不容易)。让我们慢慢来。
首先,它是由micrometer
here生成的,如果您阅读了它的说明,则:
增加一个GC之后到下一个GC之前的年轻一代内存池的大小
对您来说也可能毫无意义。我不得不看一下计算它的代码,以了解它的作用。
如果您了解GC和look at this code的工作原理,那么实际上很简单。
世代的垃圾收集器(如G1
)将堆划分为个区域(young
和old
)。新对象的分配发生在较年轻的区域(除非humongous
,但我不会参与),尤其是在Eden space
中。触发GC后,将清除Eden
,然后可以再次进行分配。这是相当简化的,并不是完全正确的(major/mixed
集合的情况稍有不同)。
现在已经有了该理论,您可以从:
看一下isYoungGenPool
是什么。
if (youngGenPoolName != null) {
final long youngBefore = before.get(youngGenPoolName).getUsed();
final long youngAfter = after.get(youngGenPoolName).getUsed();
final long delta = youngBefore - youngGenSizeAfter.get();
youngGenSizeAfter.set(youngAfter);
if (delta > 0L) {
allocatedBytes.increment(delta);
}
}
具体来说,它的定义是here:
... endsWith(“伊甸园空间”)
这样,这段代码拍摄了快照-Used Space
中GC周期之前{em> 和 的快照,计算了Eden Space
,并将所有这些增量添加到单个值中。这就是delta
。
这种方法衡量应用程序在其生命周期中分配的数量,但只能通过 young 空间来分配。恕我直言,因为::p
它不跟踪庞大的分配(对此有不同的度量标准)
它仅适用于分代垃圾收集器(例如jvm.gc.memory.allocated
不是这样的收集器)