[英]Does allocation performance degrade on a large number of live instances when using G1?
在我们的某些应用程序从CMS转移到G1时,我注意到其中一个应用程序的启动时间延长了4倍。由于GC循环导致的应用程序停止时间不是原因。 在比较应用程序行为时,我发现这个在启动后(在一堆12G中)携带了高达2.5亿个活动对象。 进一步调查显示,在前500万次分配期间,应用程序的速度正常,但随着活动对象池的增大,性能会越来越差。
进一步的实验表明,一旦达到一定的活动对象阈值,使用G1时新对象的分配确实会减慢。 我发现活动对象数量增加一倍似乎在分配所需的时间上增加了大约2.5倍。 对于其他GC引擎,因子只有2.这确实可以解释减速。
有两个问题让我怀疑这个结论:
所以:如果有人可以告诉我我的观察结果是正确的,并且可能指向一些解释性文件,或者某些有关该领域的建议,那将会很棒。 或者,有人告诉我我做错了什么。 :)
这是一个简短的测试用例(多次运行,取平均值,扣除显示的垃圾收集时间):
import java.util.HashMap;
/**
* Allocator demonstrates the dependency between number of live objects
* and allocation speed, using various GC algorithms.
* Call it using, e.g.:
* java Allocator -Xmx12g -Xms12g -XX:+PrintGCApplicationStoppedTime -XX:+UseG1GC
* java Allocator -Xmx12g -Xms12g -XX:+PrintGCApplicationStoppedTime
* Deduct stopped times from execution time.
*/
public class Allocator {
public static void main(String[] args) {
timer(2000000, true);
for (int i = 1000000; i <= 32000000; i*=2) {
timer(i, false);
}
for (int i = 32000000; i >= 1000000; i/=2) {
timer(i, false);
}
}
private static void timer(int num, boolean warmup) {
long before = System.currentTimeMillis();
Allocator a = new Allocator();
int size = a.allocate(num);
long after = System.currentTimeMillis();
if (!warmup) {
System.out.println("Time needed for " + num + " allocations: "
+ (after - before) + " millis. Map size = " + size);
}
}
private int allocate(int numElements) {
HashMap<Integer, String> map = new HashMap<>(2*numElements);
for (int i = 0; i < numElements; i++) {
map.put(i, Integer.toString(i));
}
return map.size();
}
}
正如上面的评论所述:
你的测试用例会预先分配非常大的参考数组,这些数组是长寿命的,并且基本上占据了它们自己的区域(它们可能最终位于旧的或巨大的区域),然后用数百万个可能的其他对象填充它们住在不同的地区。
这会创建许多跨区域引用,G1可以适度处理,但不是每个区域数百万。
通过G1的启发式算法,高度互联的区域也被认为是昂贵的,因此即使它们完全由垃圾组成,也不太可能被收集。
将对象分配在一起以减少跨区域引用。
没有明确地延长它们的寿命(例如通过将它们放入某种缓存中)也允许它们在年轻代GC期间死亡,这比旧区域更容易收集,旧区域本质上累积来自不同区域的对象。
因此,总的来说,你的测试用例对G1的基于区域的性质非常不利。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.