java - Hadoop CDH5 中的垃圾收集持续时间

Question

我们有一个运行 CDH5.0.2 的四数据节点集群，通过 Cloudera Manager 包裹安装。为了将 13M 用户的行导入 HBase，我们编写了一个简单的 Python 脚本并使用了 hadoop-streaming jar。它按预期工作高达 100k 行。然后......然后，一个接一个，所有数据节点崩溃并显示相同的消息:

The health test result for REGION_SERVER_GC_DURATION  has become bad: 
Average time spent in garbage collection was 44.8 second(s) (74.60%) 
per minute over the previous 5 minute(s). 
Critical threshold: 60.00%.

按照网络上的建议(例如 [1]、 [2]、 [3])尝试解决问题的任何尝试都不会接近解决方案。 “玩”Java 堆大小是没有用的。唯一“解决”这种情况的方法是将区域服务器的垃圾收集持续时间监视周期从 5 分钟增加到 50 分钟。可以说是一个肮脏的解决方法。

我们现在没有人力来为我们的 GC 使用情况创建监视器。我们最终会，但我想知道将 1300 万行导入 HBase 怎么可能导致所有区域服务器肯定崩溃。有没有干净的解决方案？

编辑:

Datanodes 上的 JVM 选项是:

-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:-CMSConcurrentMTEnabled -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled

Datanodes 是运行 CentOS 6.5 的物理机器，每个都有 32Gb Ram 和 1Quadcore 2GHz，30Mb 缓存。

下面是我们运行的 Python 脚本的摘录。我们填充了两个表:一个以唯一用户 ID 作为 rowkey，一个 columnfamily 包含用户信息，另一个以我们可能想要访问的所有信息作为 rowkey。

#!/usr/bin/env python2.7
import sys
import happybase
import json
connection = happybase.Connection(host=master_ip)
hbase_main_table = connection.table('users_table')
hbase_index_table = connection.table('users_index_table')
header = ['ID', 'COL1', 'COL2', 'COL3', 'COL4']
for line in sys.stdin:
    l = line.replace('"','').strip("\n").split("\t")
    if l[header.index("ID")] == "ID":
        #you are reading the header
        continue
    for h in header[1:]:
        try:
            id = str(l[header.index("ID")])
            col = 'info:' + h.lower()
            val = l[header.index(h)].strip()
            hbase_table.put(id_au_bytes, {
                    col: val
                    })
            indexed = ['COL3', 'COL4']
            for typ in indexed:
               idx = l[header.index(typ)].strip()
               if len(idx) == 0:
                   continue
               row = hbase_index_table.row(idx)
               old_ids = row.get('d:s')
               if old_ids is not None:
                   ids = json.dumps(list(set(json.loads(old_ids)).union([id_au])))
               else:
                   ids = json.dumps([id_au])
               hbase_index.put(idx, {
                       'd:s': ids,
                       'd:t': typ,
                       'd:b': 'ame'
                       })
       except:
           msg = 'ERROR '+str(l[header.index("ID")])
           logging.info(msg, exc_info=True)

Answer 1

最近很多人遇到的一个主要问题是 Java 应用程序可用的 RAM 数量激增，但大多数关于调整 Java GC 的信息都是基于 32 位时代的经验。

我最近花了很多时间研究大型堆情况下的 GC，以避免可怕的“长时间停顿”。我看了这个excellent presentation几次，最后 GC 和我遇到的问题开始变得更有意义了。

我对 Hadoop 了解不多，但我认为您可能遇到了年轻一代太小的情况。不幸的是，大多数关于 JVM GC 调优的信息都没有强调对象 GC 的最佳位置是在年轻代。此时收集垃圾几乎不需要时间。我不会详细介绍(如果您想知道，请观看演示)但会发生什么，如果您在年轻(新一代)中没有足够的空间，它会过早地填满。这会强制进行一次收集，并且一些对象将被移动到老年代。最终，tenured generation 会被填满，它也需要被收集起来。如果你的老年代有很多垃圾，这可能会非常慢，因为老年代收集算法通常是标记清除，它有一个非零时间来收集垃圾。

我认为您正在使用 Hotspot。这是热点的各种 GC 参数的一个很好的引用。 JVM GC options

我将从大大增加年轻一代的规模开始。我在这里的假设是正在创建许多中短生命周期的对象。你想要避免的是将这些人提升到终身一代。你这样做的方法是延长他们在年轻一代中度过的时间。为此，您可以增加它的大小(因此需要更长的时间来填满)或增加终身阈值(本质上是对象将保留的年轻集合的数量)。 tenuring threshold 的问题是在年轻一代中移动对象需要时间。增加新生代的大小在内存方面效率低下，但我猜你有很多空闲空间。

我已将此解决方案与缓存服务器一起使用，我有 > 100 毫秒范围内的次要收集和不频繁(每天少于一次)的主要收集，通常低于 0.5 秒，堆大约为 4GB。我们的对象可以活 5 分钟、15 分钟或 29 天。

您可能要考虑的另一件事是最近(相对而言)添加到 HotSpot 的 G1(垃圾优先)收集器。

我很想知道这条建议对您的效果如何。祝你好运。