客戶端

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

ScannerTimeoutException或UnknownScannerException

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

請(qǐng)參閱掃描緩存。

Thrift和Java API的性能差異

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

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

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

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

從0.20.0開始，`org.apache.hadoop.hbase.*`的默認(rèn)日志級(jí)別為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。

長(zhǎng)客戶端暫停壓縮

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

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

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

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

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

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

您可能會(huì)遇到以下錯(cuò)誤：

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錯(cuò)誤引起的。這些錯(cuò)誤導(dǎo)致舊版本的krb5-server錯(cuò)誤地阻止從Principal發(fā)送的后續(xù)請(qǐng)求。這導(dǎo)致krb5-server阻止從一個(gè)客戶端發(fā)送的連接（每個(gè)RegionServer具有多個(gè)線程連接實(shí)例的HTable實(shí)例）；客戶端日志中記錄了諸如Request is a replay (34)之類的消息，您可以忽略這些消息，因?yàn)槟J(rèn)情況下，HTable將為每個(gè)失敗的連接重試5 * 10（50）次。如果重試后與RegionServer的任何連接失敗，HTable將拋出IOException，以便HTable實(shí)例的用戶客戶端代碼可以進(jìn)一步處理它。注意：HTable在HBase 1.0中棄用，使用Table。

或者，將krb5-server更新為解決這些問題的版本，例如krb5-server-1.10.3。有關(guān)詳細(xì)信息，請(qǐng)參閱JIRA HBASE-10379。

ZooKeeper客戶端連接錯(cuò)誤

像這樣的錯(cuò)誤：

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ò)問題而無(wú)法訪問。

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

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

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

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

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

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

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

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

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

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

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