阿帕奇风暴工人内存泄漏 - 外堆

我有一个4节点风暴集群。工人JVM参数如下：阿帕奇风暴工人内存泄漏 - 外堆

-Xms5g -Xmx15g -XX:+UseG1GC -XX:MaxDirectMemorySize=1024m

风暴版本：0.9.3

问题是：工作者趋于显著当处理存储器达到14 + GB减速。

在贴紧时我的顶部输出如下。

PID USER  PR NI VIRT RES SHR S %CPU %MEM  TIME+ COMMAND                                 
2075 root  20 0 18.132g 8.372g 12368 S 57.2 28.3 18:27.44 java

GC日志：

3317.095: [GC pause (young), 0.1861930 secs] 
    [Parallel Time: 180.9 ms, GC Workers: 4] 
     [GC Worker Start (ms): Min: 3317095.5, Avg: 3317095.5, Max: 3317095.5, Diff: 0.0] 
     [Ext Root Scanning (ms): Min: 29.0, Avg: 29.4, Max: 29.7, Diff: 0.7, Sum: 117.4] 
     [Update RS (ms): Min: 18.0, Avg: 18.1, Max: 18.3, Diff: 0.3, Sum: 72.5] 
     [Processed Buffers: Min: 31, Avg: 41.2, Max: 53, Diff: 22, Sum: 165] 
     [Scan RS (ms): Min: 0.6, Avg: 0.7, Max: 0.8, Diff: 0.2, Sum: 2.8] 
     [Code Root Scanning (ms): Min: 0.1, Avg: 0.1, Max: 0.1, Diff: 0.1, Sum: 0.4] 
     [Object Copy (ms): Min: 132.1, Avg: 132.5, Max: 132.7, Diff: 0.6, Sum: 529.8] 
     [Termination (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0] 
     [GC Worker Other (ms): Min: 0.0, Avg: 0.0, Max: 0.1, Diff: 0.0, Sum: 0.2] 
     [GC Worker Total (ms): Min: 180.7, Avg: 180.8, Max: 180.8, Diff: 0.1, Sum: 723.1] 
     [GC Worker End (ms): Min: 3317276.3, Avg: 3317276.3, Max: 3317276.3, Diff: 0.0] 
    [Code Root Fixup: 0.1 ms] 
    [Code Root Migration: 0.2 ms] 
    [Clear CT: 0.4 ms] 
    [Other: 4.6 ms] 
     [Choose CSet: 0.0 ms] 
     [Ref Proc: 1.4 ms] 
     [Ref Enq: 0.1 ms] 
     [Free CSet: 1.5 ms] 
    [Eden: 2366.0M(2366.0M)->0.0B(1808.0M) Survivors: 94.0M->106.0M Heap: 5052.0M(15.0G)->2698.0M(15.0G)] 
[Times: user=0.73 sys=0.00, real=0.19 secs]

我只能看到2698 MB的堆的使用。但Linux Top显示RES的内存为8.372g。当Top内存达到〜15GB时，进程将开始堵塞，我想避免。

此外，我已经缩小了使用XX：MaxDirectMemorySize由一些外部API堵塞直接内存的可能性。

由于堆大小很大 - 如果我尝试使用探查器（我的案例中的yourkit）拍摄内存快照，工作人员崩溃。

我需要找到内存堵塞的来源。

另外，为了避免多余的消息，我已节流使用TOPOLOGY_MAX_SPOUT_PENDING等于拓扑至5

我使用KafkaSpout - 从/net/wurstmeister/storm/storm-kafka-0.8-plus storm.kafka.KafkaSpout/

另外我提到了这个线程，它有一个类似的问题，但使用ZMQ而不是在新版本的Storm中使用Netty。

Spout memory leak

更新：当我删除我的所有螺栓，仅运行kafkaspout再有就是最小的延迟，也没有记忆的问题。所以，大概我们可以怀疑加工螺栓。

来源

2015-03-25 kaulmonish

请在帖子中添加您的水口代码。你在使用acking吗？ – 2015-03-25 15:57:16

是的，我的技术是可靠的，我使用4名Acker和4名工人。 @Gaurav：我使用wurstmeister的KafkaSpout。你想查看server.properties配置吗？ – kaulmonish 2015-03-25 17:21:19

如果您分享喷口代码，它会更好。 – 2015-03-25 18:42:11

已解决。实际上问题在于G1的占用空间对于进程内存来说很大，但是集合更加优化。

从ParallelOldGC或CMS收集器到G1，较大的JVM进程大小主要与记帐集合和集合集合等“记帐”数据结构相关。

记忆集或RSets将对象引用追踪到给定区域。堆中每个区域有一个RSet。 RSet支持并行和独立收集区域。 RSets的整体足迹影响小于5％。

收集设置或获取将在GC中收集的一组区域。在GC中，CSet中的所有实时数据都被撤出（复制/移动）。一组区域可以是伊甸园，幸存者和/或老一代。 CSets对JVM的大小影响不到1％。

来源

2015-03-27 11:35:40 kaulmonish

阿帕奇风暴工人内存泄漏 - 外堆

回答

相关问题