# Apache HBase 案例研究 ## 147.概述 本章將介紹各種性能和故障排除案例研究，這些案例研究可以為診斷 Apache HBase 集群問題提供有用的藍圖。 有關性能和故障排除的更多信息，請參閱 [Apache HBase 性能調優](#performance)和[故障排除和調試 Apache HBase](#trouble) 。 ## 148.架構設計 請參閱此處的架構設計案例研究：[架構設計案例研究](#schema.casestudies) ## 149.性能/故障排除 ### 149.1。案例研究＃1（單節點上的性能問題） #### 149.1.1。腳本 在計劃的重新啟動之后，一個數據節點開始表現出異常行為。常規 MapReduce 作業針對 HBase 表運行，這些表在 5 到 6 分鐘內定期完成，開始需要 30 或 40 分鐘才能完成。一直發現這些作業在地圖上等待并減少分配給故障數據節點的任務（例如，慢地圖任務都具有相同的輸入分割）。在分布式副本期間，當滯后節點嚴重延長副本時，情況就出現了問題。 #### 149.1.2。硬件 數據節點： * 兩個 12 核處理器 * 六個企業級 SATA 磁盤 * 24GB 的 RAM * 兩個綁定的千兆網卡 網絡： * 10 千兆位架頂式交換機 * 機架之間的 20 千兆位綁定互連。 #### 149.1.3。假設 ##### HBase“熱點”地區 我們假設我們遇到了一個熟悉的痛點：HBase 表中的“熱點”區域，其中不均勻的密鑰空間分布可能會將大量請求匯集到單個 HBase 區域，轟炸 RegionServer 進程并導致響應緩慢時間。檢查 HBase 主狀態頁面顯示對故障節點的 HBase 請求數幾乎為零。此外，對 HBase 日志的檢查表明，沒有區域分裂，壓縮或其他區域轉變正在進行中。這有效地排除了“熱點”作為觀察到的緩慢的根本原因。 ##### 具有非本地數據的 HBase 區域 我們的下一個假設是，其中一個 MapReduce 任務是從 HBase 請求數據，這些數據不是 DataNode 的本地數據，因此迫使 HDFS 通過網絡從其他服務器請求數據塊。對 DataNode 日志的檢查表明，通過網絡請求的塊非常少，表明 HBase 區域已正確分配，并且大多數必要數據位于節點上。這排除了非本地數據導致經濟放緩的可能性。 ##### 由于交換或過度工作或故障硬盤而導致 I / O 等待過多 在得出 Hadoop 和 HBase 不太可能成為罪魁禍首之后，我們繼續對 DataNode 的硬件進行故障排除。根據設計，Java 將定期掃描其整個內存空間以進行垃圾收集。如果系統內存過度使用，Linux 內核可能會進入惡性循環，耗盡其所有資源，當 Java 嘗試運行垃圾回收時，將 Java 堆從磁盤來回交換到 RAM。此外，發生故障的硬盤通常會在放棄并返回錯誤之前多次重試讀取和/或寫入。這可以表現為高 iowait，因為正在運行的進程等待讀取和寫入完成。最后，接近其性能范圍上限的磁盤將開始引起 iowait，因為它通知內核它不能再接受任何數據，并且內核將傳入數據排入內存中的臟寫池。但是，使用`vmstat(1)`和`free(1)`，我們可以看到沒有使用交換，磁盤 IO 的數量僅為每秒幾千字節。 ##### 處理器使用率過高導致速度緩慢 接下來，我們檢查系統是否由于非常高的計算負荷而緩慢執行。 `top(1)`表明系統負載高于正常值，但`vmstat(1)`和`mpstat(1)`表明用于實際計算的處理器數量很少。 ##### 網絡飽和度（獲勝者） 由于磁盤和處理器都沒有被大量使用，我們轉向了網絡接口的性能。 DataNode 有兩個千兆以太網適配器，綁定形成一個活動 - 備用接口。 `ifconfig(8)`顯示出一些不尋常的異常，即接口錯誤，溢出，幀錯誤。雖然并非聞所未聞，但這些錯誤在現代硬件上非常罕見，而現代硬件的運行應該是： ``` $ /sbin/ifconfig bond0 bond0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:10.x.x.x Bcast:10.x.x.255 Mask:255.255.255.0 UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1 RX packets:2990700159 errors:12 dropped:0 overruns:1 frame:6 <--- Look Here! Errors! TX packets:3443518196 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:2416328868676 (2.4 TB) TX bytes:3464991094001 (3.4 TB) ``` 這些錯誤立即導致我們懷疑一個或多個以太網接口可能已經協商錯誤的線路速度。通過從外部主機運行 ICMP ping 并觀察超過 700 毫秒的往返時間，并通過在綁定接口的成員上運行`ethtool(8)`并發現活動接口以 100Mbs /運行，全雙工。 ``` $ sudo ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Link partner advertised link modes: Not reported Link partner advertised pause frame use: No Link partner advertised auto-negotiation: No Speed: 100Mb/s <--- Look Here! Should say 1000Mb/s! Duplex: Full Port: Twisted Pair PHYAD: 1 Transceiver: internal Auto-negotiation: on MDI-X: Unknown Supports Wake-on: umbg Wake-on: g Current message level: 0x00000003 (3) Link detected: yes ``` 在正常操作中，ICMP ping 往返時間應為 20ms 左右，接口速度和雙工應分別為“1000MB / s”和“Full”。 #### 149.1.4。解析度 在確定活動的以太網適配器速度不正確之后，我們使用`ifenslave(8)`命令使備用接口成為活動接口，從而立即提高了 MapReduce 的性能，并使網絡吞吐量提高了 10 倍： 在下一次數據中心之旅中，我們確定線路速度問題最終是由更換的壞網線引起的。 ### 149.2。案例研究＃2（2012 年績效研究） 調查結果自我描述“我們不確定什么是錯的，但似乎很慢”的問題。 [http://gbif.blogspot.com/2012/03/hbase-performance-evaluation-continued.html](http://gbif.blogspot.com/2012/03/hbase-performance-evaluation-continued.html) ### 149.3。案例研究＃3（2010 年績效研究）） 從 2010 年開始對一般集群性能的調查結果。雖然這項研究是在較舊版本的代碼庫上進行的，但這種寫法在方法方面仍然非常有用。 [http://hstack.org/hbase-performance-testing/](http://hstack.org/hbase-performance-testing/) ### 149.4。案例研究＃4（max.transfer.threads 配置） 配置`max.transfer.threads`（以前稱為`xcievers`）并診斷錯誤配置錯誤的案例研究。 [http://www.larsgeorge.com/2012/03/hadoop-hbase-and-xceivers.html](http://www.larsgeorge.com/2012/03/hadoop-hbase-and-xceivers.html) 另請參見 [`dfs.datanode.max.transfer.threads`](#dfs.datanode.max.transfer.threads) 。