Java 垃圾收集 - CPU 峰值 - 更长的连接建立时间
我们有一个位于负载均衡器后面的服务器池。该池中的机器平均每 6 秒进行一次垃圾收集。垃圾收集大约需要半秒。我们还看到垃圾收集期间 CPU 出现峰值。
客户端计算机一天中与服务器建立连接的平均时间激增近 10%。
理论：CPU 正忙于进行 GC，这就是它无法更快地分配连接的原因。
这是一个有效的理论吗？
JVM：IBM GC算法：gencon 苗圃：5 GB 堆大小：18 GB
We have a pool of server that sits behind the load balancer. The machines in this pool does garbage collection every 6 seconds on average. It takes almost half a second to garbage collect. We also see a CPU spike during garbage collection.
The client machines see a spike in average time to make a connection to the server almost 10% during a day.
Theory : CPU is busy doing GC and that's why it cannot allocate a connection faster.
Is it a valid theory?
JVM : IBM
GC algorithm :gencon
Nursery : 5 GB
Heap Size : 18 GB
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我想说的是，有了这么多的分配，所有的赌注都会被取消——随着时间的推移，它绝对会变得更糟，我的意思是，如果你整天每 6 秒进行一次 GC，这似乎是有问题的。
您有权访问该代码吗？是否可以重写它以重用对象并使分配更加智能？我已经完成了一些嵌入式系统，诀窍是一旦系统启动并运行，就永远不要调用 new （如果您可以控制整个系统，这是非常可行的）
如果您无权访问代码，请检查一些可用的 GC 调整选项（包括所使用的垃圾收集器的选择）——均随 JDK 和第 3 方选项一起分发。您可以通过一些命令行修改来提高性能。
I'd say with that many allocations all bets are off--it could absolutely get worse over time, I mean if you are doing GC every 6 seconds all day long that seems problematic.
Do you have access to that code? Can it be re-written to reuse objects and be more intelligent about allocation? I've done a few embedded systems and the trick is to NEVER call new once the system is up and running (Quite doable if you have control over the entire system)
If you don't have access to the code, check into some of the GC tuning options available (including the selection of the garbage collector used)--both distributed with the JDK and 3rd party options. You may be able to improve performance with a few command-line modifications.
我猜有可能。
鉴于垃圾回收是一个如此密集的过程，有什么理由让它每 6 秒发生一次吗？我不熟悉 IBM JVM 或您正在使用的特定收集算法，因此我无法对它们发表评论。不过，Sun 提供了一些很好的调优文档（现在由 Oracle 提供），其中讨论了不同类型的收集器以及何时使用它们。请参阅此链接了解一些想法。
证明你的理论的一种方法是添加一些代码来记录请求连接的时间和实际分配连接的时间。如果 GC 相关的 CPU 峰值似乎与分配连接的较长时间一致，那么这就证明了您的理论。然后你的问题将变成如何解决它。
It's possible I guess.
Given garbage collection is such an intensive process, is there any reason for it to occur every 6 seconds? I'm not familiar with the IBM JVM or the particular collection algorithm you are using so I can't really comment on those. However, there are some good tuning documents provided by Sun (now offered by Oracle) that discuss the different types of collectors and when you would use them. See this link for some ideas.
One way to prove your theory could to be add some code that logs the time a connection was requested and the time when it was actually allocated. If the GC related CPU spikes seem to coincide with longer times in allocating connections, then that'd prove your theory. Your problem will then become how to get around it.