故障排除和調試HBase：客戶端

客戶端

有關HBase客戶端的更多信息，請參閱客戶端。

ScannerTimeoutException或UnknownScannerException

如果從客戶端到RegionServer的RPC調用之間的時間超過掃描超時，則拋出此異常。例如，如果Scan.setCaching設置為500，然后在ResultScanner上每調用500個.next()行，就會有一個RPC調用來獲取下一批行，因為數據正以500行為一個塊的形式傳輸到客戶端。減少setCaching值可能是一個選項，但將此值設置得太低會導致對行數的處理效率低下。

請參閱掃描緩存。

Thrift和Java API的性能差異

如果Scan.setCaching太高，可能會出現(xiàn)性能不佳，甚至可能發(fā)生ScannerTimeoutExceptions，如上文的“ScannerTimeoutException或UnknownScannerException”中所述。如果Thrift客戶端對給定工作負載使用錯誤的緩存設置，則與Java API相比，性能會受到影響。要在Thrift客戶端中為給定掃描設置緩存，請使用該scannerGetList(scannerId, numRows)方法，其中numRows是一個表示要緩存的行數的整數。在一個案例中，我們發(fā)現(xiàn)在相同的查詢條件下，將Thrift掃描的緩存從1000減少到100，。

調用Scanner.next時的LeaseException

在某些情況下，從RegionServer獲取數據的客戶端會獲得LeaseException而不是通常的ScannerTimeoutException或UnknownScannerException。通常，例外的來源是org.apache.hadoop.hbase.regionserver.Leases.removeLease(Leases.java:230)（行號可能會有所不同）。它往往發(fā)生在緩慢/凍結的RegionServer#next調用中?？梢酝ㄟ^hbase.rpc.timeout > hbase.regionserver.lease.period來防止它。Harsh J調查了該問題，作為郵件列表線程HBase的一部分，mail＃user - Lease不存在異常。

Shell或客戶端應用程序在正常操作期間會引發(fā)許多可怕的異常

從0.20.0開始，`org.apache.hadoop.hbase.*`的默認日志級別為DEBUG。

在您的客戶端上，編輯$ HBASE_HOME / conf / log4j.properties，并更改log4j.logger.org.apache.hadoop.hbase=DEBUG為：log4j.logger.org.apache.hadoop.hbase=INFO，或者甚至log4j.logger.org.apache.hadoop.hbase=WARN。

長客戶端暫停壓縮

這是關于Apache HBase dist-list的一個相當常見的問題。這種情況下，客戶端通常將大量數據插入到相對未優(yōu)化的HBase集群中。壓縮會加劇暫停，盡管它不是問題的根源。

請參閱用于預創(chuàng)建區(qū)域的模式上的“表創(chuàng)建：預創(chuàng)建區(qū)域”，并確認該表不是以單個區(qū)域開始的。

對于集群配置，請參考HBase配置，特別是hbase.hstore.blockingStoreFiles，hbase.hregion.memstore.block.multiplier，MAX_FILESIZE（區(qū)域的大?。蚆EMSTORE_FLUSHSIZE.

暫停原因可能發(fā)生的稍長解釋如下：在MemStores上有時會阻塞Puts，這些Plusher被阻塞的刷新線程阻塞，因為壓縮文件太多而無法壓縮，因為壓縮程序有太多小文件要壓縮而且必須重復壓縮相同的數據。即使是輕微的壓縮，也可能發(fā)生這種情況。更糟糕的是，Apache HBase不會壓縮內存中的數據。因此，存儲在MemStore中的64MB可能在壓縮后變?yōu)?MB文件 - 這導致更小的StoreFile。好處是更多的數據被打包到同一個區(qū)域，但是通過能夠編寫更大的文件來實現(xiàn)性能 - 這就是為什么HBase在寫入新的StoreFile之前等待flushsize的原因。較小的StoreFiles成為壓縮的目標。如果不進行壓縮，文件就會大得多，不需要那么多的壓縮，但是這是以I/O為代價的。

有關其他信息，請參閱具有壓縮的長客戶端暫停上的此線程。

安全客戶端連接（[由GSS異常引起：未提供有效憑據...]）

您可能會遇到以下錯誤：

Secure Client Connect ([Caused by GSSException: No valid credentials provided
        (Mechanism level: Request is a replay (34) V PROCESS_TGS)])

此問題是由MIT Kerberos replay_cache組件中的＃1201和＃5924錯誤引起的。這些錯誤導致舊版本的krb5-server錯誤地阻止從Principal發(fā)送的后續(xù)請求。這導致krb5-server阻止從一個客戶端發(fā)送的連接（每個RegionServer具有多個線程連接實例的HTable實例）；客戶端日志中記錄了諸如Request is a replay (34)之類的消息，您可以忽略這些消息，因為默認情況下，HTable將為每個失敗的連接重試5 * 10（50）次。如果重試后與RegionServer的任何連接失敗，HTable將拋出IOException，以便HTable實例的用戶客戶端代碼可以進一步處理它。注意：HTable在HBase 1.0中棄用，使用Table。

或者，將krb5-server更新為解決這些問題的版本，例如krb5-server-1.10.3。有關詳細信息，請參閱JIRA HBASE-10379。

ZooKeeper客戶端連接錯誤

像這樣的錯誤：

11/07/05 11:26:41 WARN zookeeper.ClientCnxn: Session 0x0 for server null,
 unexpected error, closing socket connection and attempting reconnect
 java.net.ConnectException: Connection refused: no further information
        at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
        at sun.nio.ch.SocketChannelImpl.finishConnect(Unknown Source)
        at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1078)
 11/07/05 11:26:43 INFO zookeeper.ClientCnxn: Opening socket connection to
 server localhost/127.0.0.1:2181
 11/07/05 11:26:44 WARN zookeeper.ClientCnxn: Session 0x0 for server null,
 unexpected error, closing socket connection and attempting reconnect
 java.net.ConnectException: Connection refused: no further information
        at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
        at sun.nio.ch.SocketChannelImpl.finishConnect(Unknown Source)
        at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1078)
 11/07/05 11:26:45 INFO zookeeper.ClientCnxn: Opening socket connection to
 server localhost/127.0.0.1:2181

要么是由于ZooKeeper關閉，要么是由于網絡問題而無法訪問。

實用程序zkcli可能有助于調查ZooKeeper問題。

客戶端耗盡內存雖然堆大小似乎是穩(wěn)定的（但堆外/直接堆不斷增長）

您可能會遇到在郵件線程HBase，mail # user-疑似內存泄漏，中描述和處理的問題，郵件# user -疑似內存泄漏，并繼續(xù)在HBase，mail # dev - FeedbackRe:疑似內存泄漏。解決方案是為-XX:MaxDirectMemorySize向客戶端JVM傳遞一個合理的值。默認情況下，MaxDirectMemorySize等于-Xmx最大堆大小設置(如果設置了-Xmx)。嘗試將其設置為較小的值(例如，一個用戶在客戶端堆為12g時成功地將其設置為1g)。如果你把它設置得太小，它就會導致fullgc，所以要把它設置得大一點。只有在運行新的實驗性服務器端堆外緩存時，您才希望將此設置設置為客戶端，因為此特性依賴于能夠使用大的直接緩沖區(qū)(您可能必須保持單獨的客戶端和服務器端配置dirs)。

安全客戶端無法連接（[由GSS異常引起：未提供有效憑據（機制級別：無法找到任何Kerberos tgt）]）

導致此問題的原因可能有多種。

首先，檢查您是否擁有有效的Kerberos ticket。這是需要的，為了與安全的Apache HBase集群建立通信。通過運行klist命令行實用程序，檢查當前在憑證緩存中的ticket（如果有）。如果未列出ticket，則必須通過運行帶有指定密鑰表的kinit命令或通過交互方式輸入所需主體的密碼來獲取ticket。

然后，請參閱“Java安全指南疑難解答”部分。通過將javax.security.auth.useSubjectCredsOnly系統(tǒng)屬性值設置為false，可以解決最常見的問題。

由于MIT Kerberos寫入其憑證緩存的格式發(fā)生了變化，因此Oracle JDK 6 Update 26及更早版本中存在一個錯誤，導致Java無法讀取由MIT Kerberos 1.8.1或更高版創(chuàng)建的Kerberos憑證緩存。如果您的環(huán)境中存在這種有問題的組件組合，要解決此問題，請先使用kinit登錄，然后立即使用kinit -R刷新憑證緩存。刷新將重寫憑證緩存而不會出現(xiàn)有問題的格式設置。

在JDK 1.4之前，JCE是一個非捆綁產品，因此，JCA和JCE通常被稱為獨立的，不同的組件。由于JCE現(xiàn)在捆綁在JDK 7.0中，因此區(qū)別越來越不明顯。由于JCE使用與JCA相同的架構，因此JCE應該更恰當地被視為JCA的一部分。

由于JDK 1.5或更早版本，您可能需要安裝Java Cryptography Extension或JCE。確保JCE jar在服務器和客戶端系統(tǒng)上的類路徑中。

您可能還需要下載無限強度的JCE策略文件。解壓縮并解壓縮下載的文件，并將策略jar安裝到<java-home>/lib/security中。