可能導緻Hypertable啟動慢的原因

       叢集中發現了一個問題：/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值有關系，其值越小，啟動越快，但入庫速度越慢，反之亦然。在現場叢集中，需要在入庫速度和啟動時間之間進行權衡。