我在我的應用程序服務器(-cum web-server)中使用HBase客戶端與HBase 使用CDH3u4(HBase-0.90)的6個節點的集羣設置。 HBase的/ Hadoop的服務集羣上運行 是:HBase客戶端寫入性能不佳
NODENAME-- ROLE
Node1 -- NameNode
Node2 -- RegionServer, SecondaryNameNode, DataNode, Master
Node3 -- RegionServer, DataNode, Zookeeper
Node4 -- RegionServer, DataNode, Zookeeper
Node5 -- RegionServer, DataNode, Zookeeper
Node6 -- Cloudera Manager, RegionServer, DataNode
我用我的HBase客戶端以下優化:
- 自動沖水=假
- ClearbufferOnFail =真
- HTable BUFFERSIZE = 12MB
- Put setWriteToWAL = false(我很好,丟失了1個數據)。
爲了在讀取和寫入之間保持一致,我打電話給 flush-commitits在所有緩衝表中每隔2秒。
在我的應用程序中,我將HBase寫入調用放入隊列(異步方式),並使用20個Consumer線程排空隊列。在使用curl在本地點擊網絡服務器 時,curl完成後,我能夠看到2500的HBase的TPS,但帶有負載測試的 ,其中請求將以每秒1200點的高速率進行 在3個應用程序服務器上消費者(消耗)線程負責 寫入HBase不寫入數據的速度與輸入速率相當。當請求速率是每秒1200點擊時,我是 看不到超過600 TPS。
任何人都可以建議我們可以做些什麼來提高性能?我已經嘗試用 將3個應用程序服務器上的線程數減少爲7,但仍然無效。專家 的意見將是有幫助的。由於這是一臺生產服務器,所以不要考慮 交換角色,除非有人指出嚴重的性能優勢。爲了突出/闡明我們的HBase寫作模式,我們的第一個事務檢查表A中的行(使用HTable.exists)。它無法第一次找到該行,因此寫入三個表。後續的4交易在表A上進行存在檢查,並且當它發現該行時,它只寫入1個表。
感謝您的洞察力eclark。我們從權威指南中得到了一些相同的反饋(預分割,處理程序),所以也納入了這些反饋。然而爲了測試它們在負載下的有效性。但是,想要了解您突出顯示的幾點。壓縮 - 你是指表壓縮策略,即GZIP,LZO等?並檢查磁盤IO,這是HBase對HDFS所做的事情嗎? –
壓縮:是的,我的意思是列家庭壓縮LZO/Snappy/LZ4(遠離gzip作爲經驗法則)。 檢查磁盤IO:確保它是均勻的。確保沒有太多。 > 90兆字節每秒寫不會真的工作很長時間。你在某個時候會有磁盤隊列。 – eclark