可能导致Hypertable启动慢的原因

水深无声 2022-03-27 06:18 210阅读 0赞

集群中发现了一个问题：/hypertable/servers/rs1/log/user目录下有上百个文件，并且其余rs的相同路径下也是如此。然后集群重启时，Hypertable不紧不慢的回放着CommitLog，粗略估计了一下，平均一个CommitLog文件的回放需要至少一分钟，整个集群重启时间竟然需要数个小时。

Hypertable在早期的版本中存在一个bug，其会 阻止后台 maintenance进程的执行，从而导致CommitLog文件的积压。 可能采取以下步骤确认此bug：  
    1.停止Hypertable  
    2.启动任一台RangeServer的DfsBroker服务  
    /opt/hypertable/current/bin/start-dfsbroker hadoop  
    3. 运行下列命令  
    /opt/hypertable/current/bin/ht metalog\_dump /hypertable/servers/rs1/log/rsml | grep "load\_acknowledged=false" | wc -l  
    如果命令返回一个非零的结果，表示此bug存在，需要使用官方提供的特定工具触发 maintenance进程。 很遗憾，我没有机会得到这个工具，因为我幸运的得到了结果0.。。。。。更幸运的是知道了另一种可能导致此问题的情况和解决方法。  
    Hypertable执行插入操作时，先将数据写入CommitLog文件，再写入内存中的CellCache，然后给客户端返回插入OK的响应信息。CellCache写满后才会持久化到HDFS，理想情况下，此时的后台maintenance进程应该删除对应的CommitLog文件。但是由于一个CommitLog中一般会包含多个range的数据，只有在这些range都被“妥善安排”后，CommitLog才可以被删除，并且maintenance进程开销较大，为了保证较快的插入速度，maintenance进程也不能频繁实施，所以就出现CommitLog积攒的情况。  
    Hypertable也提供了控制CommitLog的两个配置项：Hypertable.RangeServer.CommitLog.PruneThreshold.Min和Hypertable.RangeServer.CommitLog.PruneThreshold.Max，分别表示一个RangeServer中CommitLog可以积攒的最小值和最大值，前者默认值为1G，后者没有默认值，即上不封顶。CommitLog如果小于最小值，则无需删除；如果处于两者之间，将由Hypertable根据集群负载状况自动调度maintenance进程进行删除；如果大于最大值，则强制调度maintenance进程进行删除，即不允许其超过最大值。  
    我的集群没有设置Hypertable.RangeServer.CommitLog.PruneThreshold.Max，故Hypertable将根据集群负载状况自动调度maintenance进程删除CommitLog，我的入库负载也较大，故出现了CommitLog堆积了上百个文件的情况，并导致Hypertable重启花费数个小时的问题。当我将 Hypertable.RangeServer.CommitLog.PruneThreshold.Max设为1G时，每个RangeServer目录下的CommitLog文件数目就变为10几个了，启动就变为10几分钟了.

综上所述：重启慢与Hypertable.RangeServer.CommitLog.PruneThreshold.Max值有关系，其值越小，启动越快，但入库速度越慢，反之亦然。在现场集群中，需要在入库速度和启动时间之间进行权衡。