Java 堆空间监控 - 我们做错了吗？
我们有一个 Nagios 检查来检查某些 Tomcat 实例上的堆内存状态。它用于从虚拟机获取指标的命令如下：
java -jar /usr/java/cmdline-jmxclient-0.10.3.jar - localhost:17757 java.lang:type=Memory HeapMemoryUsage
该命令会生成如下输出：
committed: 132579328
init: 134217728
max: 401014784
used: 18831512
如果 used 的值大于 值的 90%，则会启动警报最大。这对我来说似乎是有缺陷的，主要是因为 max 的值可以下降也可以上升:)
我们应该使用什么信息来正确监控堆空间的消耗？
我应该将 max 与 Xmx 的值进行比较吗？
我可以使用以下命令检索 Xmx 的值：
java -jar /usr/java/cmdline-jmxclient-0.10.3.jar - localhost:17757 java.lang:type=Runtime InputArguments
有更好的方法吗？
We have a Nagios check that checks the heap memory state on some Tomcat instances. The command it uses to get metrics back from the VM is the following:
java -jar /usr/java/cmdline-jmxclient-0.10.3.jar - localhost:17757 java.lang:type=Memory HeapMemoryUsage
Which produces output such as:
committed: 132579328
init: 134217728
max: 401014784
used: 18831512
An alert is kicked off if the value against used is greater than 90% of the value against max. This seems flawed to me, mainly because the value of max can go down as well as up :)
What information should we be using to monitor correctly the consumption of heap space?
Should I be comparing max with the value of Xmx?
I can retrieve the value of Xmx using the following command:
java -jar /usr/java/cmdline-jmxclient-0.10.3.jar - localhost:17757 java.lang:type=Runtime InputArguments
Is there a better way?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
根据我的观察，“最大”值会波动。监视示例 Java 进程，已使用的堆如您所期望的那样变化，但是当已使用的堆接近这些限制时，提交的值和最大值也会动态调整大小（我相信比率是可配置的）。
就我而言，Xmx 标志设置为 9 GiB，奇怪的是，提交的值和最大值偶尔会超过此值（9.2 GiB）？
Java 倾向于积极利用可用堆空间，因此使用的堆大小偶尔达到 100% 不会让我感到困扰。相反，我对最后 5 分钟、10 分钟和 15 分钟等的平均值更感兴趣。如果已用堆长时间保持在 90% 以上，您可能会遇到问题 - 检查 GC 开销将是一个很好的指标（显然还有任何 OOME）。
From my observations, the "max" value fluctuates. Monitoring an example Java process, the used heap varies as you'd expect, but the committed and max values also size dynamically as the used heap approaches those limits (I believe the ratios are configurable).
In my case, the Xmx flag was set to 9 GiB and strangely, the committed and max values occasionally exceeded this (9.2 GiB)?
Java tends to make aggressive use of available heap space, so a used heap size occasionally hitting 100% wouldn't bother me. Instead, I'd be more interested in the average of the last 5, 10 and 15 minutes etc. If the used heap stays above 90% for long periods, you may have a problem - checking your GC overhead would be a good indicator (and any OOME's obviously).