4

我们有一个运行 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 使用情况创建监视器。我们最终会的，但我想知道将 13M 行导入 HBase 怎么可能导致所有区域服务器肯定崩溃。有干净的解决方案吗？

编辑：

Datanodes 上的 JVM 选项有：

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

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

下面是我们运行的 Python 脚本的摘录。我们填充了两个表：一个具有唯一用户 ID 作为行键，一个包含用户信息的列族，另一个具有我们可能希望作为行键访问的所有信息。

#!/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)
4

1 回答 1

3

如今，许多人遇到的主要问题之一是 Java 应用程序可用的 RAM 数量激增，但有关调整 Java GC 的大部分信息都是基于 32 位时代的经验。

我最近花了很多时间研究大型堆情况下的 GC，以避免可怕的“长时间停顿”。我多次观看这个出色的演示文稿，最后 GC 和我面临的问题开始变得更有意义。

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

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

我会从大幅增加年轻一代的规模开始。我在这里的假设是正在创建许多中短寿命的对象。你想要避免的是让这些被提升到终身一代。你这样做的方式是延长他们在年轻一代中度过的时间。要做到这一点，您可以增加它的大小（因此填充需要更长的时间）或增加使用期限（本质上是对象将保留的年轻集合的数量）。使用期限阈值的问题是在年轻代中移动对象需要时间。增加年轻代的大小在内存方面效率低下，但我猜你有很多空闲。

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

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

我对这个建议对你的效果很感兴趣。祝你好运。

于 2015-01-16T16:12:33.393 回答