有关 HBase 客户端的更多信息，请参阅客户端。
如果从客户端到 RegionServer 的 RPC 调用之间的时间超过扫描超时，则抛出此异常。例如，如果Scan.setCaching设置为 500，那么将在 ResultScanner 上每 500 .next()次调用一次 RPC 调用来获取下一批行，因为数据正以 500 行的块传输到客户端。减少 setCaching 值可能是一个选项，但将此值设置得太低会导致对行数的低效处理。
参见扫描缓存。
如果Scan.setCaching太高，可能会出现性能不佳甚至ScannerTimeoutExceptions，如 ScannerTimeoutException 或 UnknownScannerException 中所述。如果 Thrift 客户端对给定工作负载使用了错误的缓存设置，则与 Java API 相比，性能会受到影响。要在 Thrift 客户端中为给定扫描设置缓存，请使用scannerGetList(scannerId, numRows)方法，其中numRows是表示要缓存的行数的整数。在一个案例中，发现将 Thrift 扫描的缓存从 1000 减少到 100，在给定相同查询的情况下，将性能提高到与 Java API 接近。
另见 Jesse Andersen 的博客文章关于在 Thrift 中使用 Scans。
Scanner.next时LeaseException在某些情况下，从 RegionServer 获取数据的客户端会获得 LeaseException 而不是通常的 ScannerTimeoutException 或 UnknownScannerException 。通常，例外的来源是org.apache.hadoop.hbase.regionserver.Leases.removeLease(Leases.java:230)（行号可能不同）。它往往发生在缓慢/冻结RegionServer#next调用的环境中。可以通过hbase.rpc.timeout>来防止它。 hbase.client.scanner.timeout.period。 Harsh J 调查了该问题，作为邮件列表线程的一部分 HBase，邮件#user-租约不存在异常
从 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 的一个相当常见的问题。场景是客户端通常将大量数据插入到相对未优化的 HBase 集群中。压缩会加剧暂停，尽管它不是问题的根源。
有关预创建区域的模式，请参见表创建：预创建区域，并确认该表不是以单个区域开头。
有关群集配置，请参阅 HBase 配置，特别是hbase.hstore.blockingStoreFiles，hbase.hregion.memstore.block.multiplier，MAX_FILESIZE（区域大小）和MEMSTORE_FLUSHSIZE.
稍微更长时间解释为什么会发生暂停的原因如下：在 MemStores 上有时会阻塞 Puts，它被阻塞的刷新线程阻塞，因为有太多的文件需要压缩，因为压缩器有太多的小文件要压缩而且必须重复压缩相同的数据。即使是轻微的压缩也会发生这种情况。使这种情况更加复杂，Apache HBase 不会压缩内存中的数据。因此，存储在 MemStore 中的 64MB 可能在压缩后变为 6MB 文件 - 这导致更小的 StoreFile。好处是更多的数据被打包到同一个区域，但是通过能够编写更大的文件来实现性能 - 这就是为什么 HBase 在写入新的 StoreFile 之前等待 flushsize 的原因。较小的 StoreFiles 成为压缩的目标。如果没有压缩，文件会更大，并且不需要那么多的压缩，但这是以 I / O 为代价的。
有关其他信息，请参阅长客户端暂停压缩上的此主题。
您可能会遇到以下错误：
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 发送的后续请求。这导致 krb5-server 阻止从一个客户端发送的连接（一个具有多个线程连接实例的 HTable 实例用于每个 RegionServer）;客户端日志中记录了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 。
像这样的错误......
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 问题。
您可能遇到了在邮件线程 HBase，mail＃user - 疑似内存泄漏中描述和处理的问题，并继续在 HBase，邮件#dev - FeedbackRe：怀疑内存泄漏。解决方法是将客户端 JVM 传递给-XX:MaxDirectMemorySize合理的值。默认情况下，MaxDirectMemorySize等于-Xmx最大堆大小设置（如果设置了-Xmx）。尝试将其设置为较小的值（例如，当一个用户具有12g的客户端堆时，成功将其设置为1g）。如果你把它设置得太小，它会带来FullGCs所以保持它有点沉重。您希望仅在客户端进行此设置，尤其是在运行新的实验性服务器端堆外缓存时，因为此功能取决于能否使用大型直接缓冲区（您可能必须保持单独的客户端和服务器 - side config dirs）。
导致此症状的原因可能有多种。
首先，检查您是否拥有有效的 Kerberos 票证。为了建立与安全的 Apache HBase 集群的通信，需要一个。通过运行klist命令行实用程序，检查当前在凭证缓存中的票证（如果有）。如果未列出故障单，则必须通过使用指定的密钥表运行kinit命令或通过交互方式输入所需主体的密码来获取故障单。
然后，请参阅 Java 安全指南疑难解答部分。通过将javax.security.auth.useSubjectCredsOnly系统属性值设置为false来解决此处解决的最常见问题。
由于 MIT Kerberos 写入其凭据缓存的格式发生了变化，因此 Oracle JDK 6 Update 26 及更早版本中存在一个错误，导致 Java 无法读取由 MIT Kerberos 1.8.1 版本创建的 Kerberos 凭据缓存或更高。如果您的环境中存在这种有问题的组件组合，要解决此问题，请首先使用kinit登录，然后立即使用kinit -R刷新凭据缓存。刷新将重写凭证缓存而不会出现有问题的格式。
在 JDK 1.4 之前，JCE 是一个非捆绑产品，因此，JCA 和 JCE 通常被称为独立的，不同的组件。由于 JCE 现在捆绑在 JDK 7.0 中，因此区别越来越明显。由于 JCE 使用与 JCA 相同的架构，JCE 应该更恰当地被认为是 JCA 的一部分。
由于 JDK 1.5 或更早版本，您可能需要安装 Java 密码术扩展或 JCE。确保 JCE jar 位于服务器和客户端系统上的类路径中。
您可能还需要下载无限强度 JCE 策略文件。解压缩并解压缩下载的文件，并将策略 jar 安装到 <java-home>/ lib / security</java-home> 中。