hadoop集群执行任务结束会不会自动释放jvm内存吗

发布网友发布时间：2022-04-14 04:30

共2个回答

懂视网时间：2022-04-14 08:51

背景：公司在线上使用了CDH5集群，一开始由于疏忽，忘记了在计划任务中定期执行Balancer来平衡各节点的数据。后来，在引入大量的Job之后，数据增长非常迅猛，有很多节点开始出现利用率超过99.9%的情况，部分Job甚至开始Failed。于是我们便执行Balancer来

背景：
公司在线上使用了CDH5集群，一开始由于疏忽，忘记了在计划任务中定期执行Balancer来平衡各节点的数据。
后来，在引入大量的Job之后，数据增长非常迅猛，有很多节点开始出现利用率超过99.9%的情况，部分Job甚至开始Failed。

于是我们便执行Balancer来清理数据，结果发现有26T的数据需要平衡，而Balancer每次只移动50G的数据，并且耗时30分钟，而集群每个小时新写入的数据会导致又有40-60G的数据需要平衡。这样一来，Balancer就根本无法胜任了。

14/10/14 20:31:11 INFO balancer.Balancer: Need to move 26.49 TB to make the cluster balanced.
14/10/14 20:31:11 INFO balancer.Balancer: Decided to move 10 GB bytes from 10.100.1.10:50010 to 10.100.1.60:50010
14/10/14 20:31:11 INFO balancer.Balancer: Decided to move 10 GB bytes from 10.100.1.20:50010 to 10.100.1.70:50010
14/10/14 20:31:11 INFO balancer.Balancer: Decided to move 10 GB bytes from 10.100.1.30:50010 to 10.100.1.80:50010
14/10/14 20:31:11 INFO balancer.Balancer: Decided to move 10 GB bytes from 10.100.1.40:50010 to 10.100.1.90:50010
14/10/14 20:31:11 INFO balancer.Balancer: Decided to move 10 GB bytes from 10.100.1.50:50010 to 10.100.1.100:50010
14/10/14 20:31:11 INFO balancer.Balancer: Will move 50 GB in this iteration
...

解决办法：
1. 增加Balancer可操作的带宽
我们思考，是否是因为Balancer的默认带宽太小，所以效率低下，于是我们尝试将Balancer的带宽扩容到了500M/s：

hadoop dfsadmin -setBalancerBandwidth 524288000

但问题并没有得到太大的改善。

2. 强行对节点进行Decommission
我们发现，当对一些节点进行Decommission操作时，上面的数据虽然有10-30T甚至更多，但总能在1天内全部Copy到其它的节点上，这里面由于默认集群副本数为3的原因，应该只有1/3的数据被复制了，但数据是完整的，并且被复制出去的数据也是平均分配到各个节点上的。那么我们何不使用它来作为一个类似Balancer的功能来解决一些磁盘用量超过99.9%的节点呢？
事实证明，这个方法非常可行，我们针对线上8个节点进行了Decommission操作（注意要尽量一台一台进行），在完成下线之后再立刻格式化数据磁盘，并重新添加回集群，新的数据也会非常快的平衡过来。比较完美的解决了之前头疼的问题，并且只花费了不到4天的时间。

3. Hadoop对LVM磁盘卷的支持问题
在解决Balancer的问题时，我们还发现，Hadoop对LVM磁盘卷的支持不是很好，表现在如果在一块磁盘上创建了逻辑卷/根分区等，再创建了逻辑卷/data1分区，Hadoop会一直将/data1写到100%，然后导致一些Job提示没有空间写入。我们猜想Hadoop应该是物理卷为单位来控制用量的。因此，我们不得不将这些包含了逻辑卷数据磁盘的主机重新安装，并分配单独的物理卷，如/dev/sda3作为/data1挂载，便再也没有以上问题。

原文地址：Hadoop运维笔记之 Balancer难以在快速增长的集群上平衡大量的数据, 感谢原作者分享。

热心网友时间：2022-04-14 05:59

1.内存hadoop为各个守护进程（namenode,secondarynamenode,jobtracker,datanode,tasktracker）统一分配的内存在hadoop-env.sh中设置，参数为HADOOP_HEAPSIZE，默认为1000M。大部分情况下，这个统一设置的值可能并不适合。例如对于namenode节点，1000M的内存只能存储几百万个文件的数据块的引用。如果我想单独设置namenode的内存，可以通过HADOOP_NAMENODE_OPTS来设置。同样的，可以通过HADOOP_SECONDARYNAMENODE_OPTS来设置secondrynamenode的内存，使得它与namenode保持一致。当然，还有HADOOP_DATANODE_OPTS、HADOOP_BALANCER_OPTS、HADOOP_JOBTRACKER_OPTS变量供你使用。此外，tasktracker启动独立的子JVM以运行map和rece任务，分配给每个子JVM的内存量由mapred.child.java.opts属性（mapred-site.xml）控制，默认值为200M。2.最大map任务数一个tasktracker能够同时运行最大map任务数，由mapred.tasktracker.map.tasks.maximum属性（mapred-site.xml）控制，默认为2。3.最大rece任务数一个tasktracker能够同时运行最大rece任务数，由mapred.tasktracker.rece.tasks.maximum属（mapred-site.xml）性控制，默认为2。4.小总结：计算节点的内存占用量。默认情况下，一个同时运行了namenode，secondarynamenode和jobtracker的主节点，各自使用1000M内存，所以总计使用3000M。默认情况下，一个从节点运行了如下守护进程：1个datanode：默认占用1000M内存。1个tasktracker：默认占用1000M内存。最多2个map任务：2*200M=400M。最多2个rece任务：2*200M=400M。即默认情况下，一个从节点需要使用2800M内存量。

hadoop集群 执行任务结束会不会自动释放jvm内存吗

hadoop集群执行任务结束会不会自动释放jvm内存吗