2024HBase in Practice-性能、監(jiān)控及問題解決

HBaseinPractice首先講一下針對IOIOHBase也有很HDDIOHDDHBaseHBase提供了很多方法，第一個就是Compaction限流，基本思想就是限制它每秒能寫出的數據量，在1.1.0版本以上才能使用，對于1.3.0版本分界線以上以下配置不同，具體配置如上圖所示。你可以設置其吞吐的上限和下限，也可以設置平峰期的限制。我們進行限流肯定其他的應用，如spark等。Flush限流是在1.3.0版本以上支持的，其實主要的IO來源就是Compaction和Flush，配置與Compaction比較像。值得注意的是限流不能過低，如flush就會delay，內存會膨脹，如果膨脹超過一定區(qū)域就會blockingupdate，會出現寫allstoresmainStoreCFflushPer-CFFlush1.1.01.1.0-2.0CFmainStore16Mflushflush。后flushCF現CF過多，因此也會有下限值控制，也是16M。使用這個功能也需要注意，開啟這個功能有很多數據是不flush，但是如果出現故障，replay的數據會變多，在HBase中有個參optionalcacheflushinterval，可以設置過多長時間強制flush一次，還有一個flush1.0log都是12塊硬盤，如果用一個WAL(writeaheadlog)，HDFS是三個副本，雖然能將吞吐一個regionserver配置4個WAL，測試性能會提升20%。版本低于1.2.0：replication存在問題,vider->multiwall,hbase.wal.regiongrouping.strategy->boundedhbase.wal.regiongrouping.numgroupsWAL是依據你的盤確定，IO能力是否充足。WALSSDSSDStoragePolicy，但該功能在2.0版本上才有。對不同的CF設置不同的Storage需要支持StoragePolicy配置，如果生成的文件都是HDD,會影響讀取的性能。ONE_SSDHDFSclientSSDbackport。對于混合磁盤環(huán)境（SSDHDD），WALONE_SSD，CFONE_SSDSSDMergeMVCCandSequenceId能問題：branch-1.01.0.3branch-1.4.0ASYNC_WALBucketCachekey1.2.0如果遠程讀SSD，需要考慮網絡開銷，ONE_SSD策略+HDFS遠程讀開銷尤其大。排隊時間。TotalCallTimeRegionServerserverHBaseserver數據看起來沒問題，這種情況需要業(yè)務debug客戶端的問題，例如是否業(yè)務程序GC，或者客戶端是不是網絡出口存在擁塞。TotalCallTime等于ProcessCallTime加上TimeserveractivehandlerQueueCallTime請求是從隊列出來后處理。ActiveHandler在1.4.0版本以前是沒有讀寫分離監(jiān)控的。讀寫分離的好處就是Handler打滿到底是讀出問題還是寫出問題就可以很容易監(jiān)控。RPC隊列長度也可以判斷機器是否出問題了，RPC連接數很高也是消耗系統(tǒng)資源。上圖是我們監(jiān)等這些都會監(jiān)控。需要說明的是對latency的監(jiān)控，HBase出問題到底是文件系統(tǒng)出問題故障的話HBase肯定會受影響，因次對于putWALsynclatency，對于get要監(jiān)控HDFSpreadlatency，Scan請求監(jiān)控HDFSreadlatency。對于HDFSpread/readlatency的監(jiān)控指標需要1.4.0版本以上才有。如果發(fā)現Get請求latencyHDFSpreadlatencyHDFS須對p999高的RegionServer一一排查。第三個就是內存相關的指標，GC相關的監(jiān)控指標對于排查問題作用未必很大（是否存在GCGCPauseTimeWithoutGCGC1.4.0hangCPU等，都會導致進程堵塞。再一個就是對BlockCache/MemStoreSize的監(jiān)控，如何監(jiān)控Hfile數過多，一方面可以監(jiān)控blockingupdate的頻率，另一方面是看MemStoreSize是否變大了。BlockCache1.3.0datametametablock命中率一般都很高，訪問頻率也很高，如果不區(qū)分開metadata，cachedatablock65meta率基本是100%。regionserverhandlerregionServerregionstaleRegionServerIO器已經出問題，因為出問題的請求沒有匯報給server，另外如果機器資源耗盡，新的請求serverservermetrics務，但是master還是可以服務。接下來講一下日志的排查，首先關于慢請求。如發(fā)現一個server的999時間很長，第一反RegionServerresponseTooSlow會打印任何有關processingtime、row等具體信息的，因此請關注HBASE-16033/HBASE-16972這兩個JIRA。會打印詳細信息，前面一個截圖是對普通請scanscanbranch-以上，branch-以上，或1.3.0以上版本。在自己的版本還做了一Upstreamlongprocesstime還是longqueueTimelongprocesstime會導致一系列的longqueueTime。如果不區(qū)分會看到很多responseTooSlow，但是你并不知道出現的問題是什么。當然還需那如果請求處理時間很接近但未到達10秒，比如8秒，對于這種慢請求怎么debug？這regionServerjstackhandlerwaitwaitClientsinglebatchbatchhbasebackoffp