故障排除和調(diào)試HBase：客戶端

客戶端

有關(guān)HBase客戶端的更多信息，請參閱客戶端。

ScannerTimeoutException或UnknownScannerException

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

請參閱掃描緩存。

Thrift和Java API的性能差異

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

調(diào)用Scanner.next時的LeaseException

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

Shell或客戶端應(yīng)用程序在正常操作期間會引發(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。

長客戶端暫停壓縮

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

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

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

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

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

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

您可能會遇到以下錯誤：

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錯誤引起的。這些錯誤導(dǎo)致舊版本的krb5-server錯誤地阻止從Principal發(fā)送的后續(xù)請求。這導(dǎo)致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。有關(guān)詳細信息，請參閱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關(guān)閉，要么是由于網(wǎng)絡(luò)問題而無法訪問。

實用程序zkcli可能有助于調(diào)查ZooKeeper問題。

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

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

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

導(dǎo)致此問題的原因可能有多種。

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

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

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

在JDK 1.4之前，JCE是一個非捆綁產(chǎn)品，因此，JCA和JCE通常被稱為獨立的，不同的組件。由于JCE現(xiàn)在捆綁在JDK 7.0中，因此區(qū)別越來越不明顯。由于JCE使用與JCA相同的架構(gòu)，因此JCE應(yīng)該更恰當?shù)乇灰暈镴CA的一部分。

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

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