Mat*_*ers 2 java heap garbage-collection heap-memory alarm
我最近发现我的一项服务在垃圾收集中占用了大量时间,因为最大堆大小太小.我开始之前服务就在那里,所以我没有意识到堆的大小.如果它回到某个点,我想设置一个警告警告我,但我也不想给它提供比实际需要更多的资源.对于垃圾收集和使用的堆百分比,您认为合理的级别是什么？
我认为平均堆使用率的警报将是~85%,并且100毫秒的gc/5分钟.
我理解这是基于要求和硬件,但我真的在寻找一些基准或标准来做出我的决定.
Alex Lockwood的回答说:
堆内存使用和GC时间的推荐"最大级别" 尽可能少.
这是误导.我实际上建议反过来.尝试挤压堆大小是一个坏主意,因为这会导致您的应用程序更频繁地运行GC,并且花费更少的时间(平均)做有用的工作.
问题基本上就是这个.当JVM用完空间来分配对象时,会运行经典(非并发)GC.然后它遍历非垃圾对象,将它们复制到不同的"空间".运行GC循环的处理器时间在很大程度上取决于非垃圾的数量......但它实现的有用工作(它释放的空间量)与之成正比heapsize - nongarbage.因此,当您挤压堆大小时,您会减少GC执行的有用工作量...对于相同的处理器时间开销.
最初的问题说:
我认为平均堆使用率的警报将是~85%,并且100毫秒的gc/5分钟.
在GC CPU使用的绝对级别上设置监视器/警报可能没有用.GC时间取决于服务器活动以及GC效率.每次服务器忙碌时,您都不希望GC警报响起.
平均堆使用率为85%是合理的警报级别,但再次将警报设置为固定级别可能会产生过多的错误警报.
另一种方法是使用JVM选项设置"在GC中花费的百分比时间"阈值,并将其与"在OutOfMemoryException上终止JVM"选项相结合,并在服务器的启动脚本中添加自动重启循环.然后监视重启.