Apache HBase 案例研究

147.概述

本章将介绍各种性能和故障排除案例研究，这些案例研究可以为诊断 Apache HBase 集群问题提供有用的蓝图。

有关性能和故障排除的更多信息，请参阅 Apache HBase 性能调优和故障排除和调试 Apache HBase 。

148.架构设计

请参阅此处的架构设计案例研究：架构设计案例研究

149.性能/故障排除

149.1。案例研究＃1（单节点上的性能问题）

149.1.1。脚本

在计划的重新启动之后，一个数据节点开始表现出异常行为。常规 MapReduce 作业针对 HBase 表运行，这些表在 5 到 6 分钟内定期完成，开始需要 30 或 40 分钟才能完成。一直发现这些作业在地图上等待并减少分配给故障数据节点的任务（例如，慢地图任务都具有相同的输入分割）。在分布式副本期间，当滞后节点严重延长副本时，情况就出现了问题。

149.1.2。硬件

数据节点：

  • 两个 12 核处理器

  • 六个企业级 SATA 磁盘

  • 24GB 的 RAM

  • 两个绑定的千兆网卡

网络：

  • 10 千兆位架顶式交换机

  • 机架之间的 20 千兆位绑定互连。

149.1.3。假设

HBase“热点”地区

我们假设我们遇到了一个熟悉的痛点：HBase 表中的“热点”区域，其中不均匀的密钥空间分布可能会将大量请求汇集到单个 HBase 区域，轰炸 RegionServer 进程并导致响应缓慢时间。检查 HBase 主状态页面显示对故障节点的 HBase 请求数几乎为零。此外，对 HBase 日志的检查表明，没有区域分裂，压缩或其他区域转变正在进行中。这有效地排除了“热点”作为观察到的缓慢的根本原因。

具有非本地数据的 HBase 区域

我们的下一个假设是，其中一个 MapReduce 任务是从 HBase 请求数据，这些数据不是 DataNode 的本地数据，因此迫使 HDFS 通过网络从其他服务器请求数据块。对 DataNode 日志的检查表明，通过网络请求的块非常少，表明 HBase 区域已正确分配，并且大多数必要数据位于节点上。这排除了非本地数据导致经济放缓的可能性。

由于交换或过度工作或故障硬盘而导致 I / O 等待过多

在得出 Hadoop 和 HBase 不太可能成为罪魁祸首之后，我们继续对 DataNode 的硬件进行故障排除。根据设计，Java 将定期扫描其整个内存空间以进行垃圾收集。如果系统内存过度使用，Linux 内核可能会进入恶性循环，耗尽其所有资源，当 Java 尝试运行垃圾回收时，将 Java 堆从磁盘来回交换到 RAM。此外，发生故障的硬盘通常会在放弃并返回错误之前多次重试读取和/或写入。这可以表现为高 iowait，因为正在运行的进程等待读取和写入完成。最后，接近其性能范围上限的磁盘将开始引起 iowait，因为它通知内核它不能再接受任何数据，并且内核将传入数据排入内存中的脏写池。但是，使用vmstat(1)和free(1)，我们可以看到没有使用交换，磁盘 IO 的数量仅为每秒几千字节。

处理器使用率过高导致速度缓慢

接下来，我们检查系统是否由于非常高的计算负荷而缓慢执行。 top(1)表明系统负载高于正常值，但vmstat(1)和mpstat(1)表明用于实际计算的处理器数量很少。

网络饱和度（获胜者）

由于磁盘和处理器都没有被大量使用，我们转向了网络接口的性能。 DataNode 有两个千兆以太网适配器，绑定形成一个活动 - 备用接口。 ifconfig(8)显示出一些不寻常的异常，即接口错误，溢出，帧错误。虽然并非闻所未闻，但这些错误在现代硬件上非常罕见，而现代硬件的运行应该是：

  1. $ /sbin/ifconfig bond0
  2. bond0  Link encap:Ethernet  HWaddr 00:00:00:00:00:00
  3. inet addr:10.x.x.x  Bcast:10.x.x.255  Mask:255.255.255.0
  4. UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
  5. RX packets:2990700159 errors:12 dropped:0 overruns:1 frame:6          <--- Look Here! Errors!
  6. TX packets:3443518196 errors:0 dropped:0 overruns:0 carrier:0
  7. collisions:0 txqueuelen:0
  8. RX bytes:2416328868676 (2.4 TB)  TX bytes:3464991094001 (3.4 TB)

这些错误立即导致我们怀疑一个或多个以太网接口可能已经协商错误的线路速度。通过从外部主机运行 ICMP ping 并观察超过 700 毫秒的往返时间，并通过在绑定接口的成员上运行ethtool(8)并发现活动接口以 100Mbs /运行，全双工。

  1. $ sudo ethtool eth0
  2. Settings for eth0:
  3. Supported ports: [ TP ]
  4. Supported link modes:   10baseT/Half 10baseT/Full
  5.                        100baseT/Half 100baseT/Full
  6.                        1000baseT/Full
  7. Supports auto-negotiation: Yes
  8. Advertised link modes:  10baseT/Half 10baseT/Full
  9.                        100baseT/Half 100baseT/Full
  10.                        1000baseT/Full
  11. Advertised pause frame use: No
  12. Advertised auto-negotiation: Yes
  13. Link partner advertised link modes:  Not reported
  14. Link partner advertised pause frame use: No
  15. Link partner advertised auto-negotiation: No
  16. Speed: 100Mb/s                                     <--- Look Here!  Should say 1000Mb/s!
  17. Duplex: Full
  18. Port: Twisted Pair
  19. PHYAD: 1
  20. Transceiver: internal
  21. Auto-negotiation: on
  22. MDI-X: Unknown
  23. Supports Wake-on: umbg
  24. Wake-on: g
  25. Current message level: 0x00000003 (3)
  26. Link detected: yes

在正常操作中，ICMP ping 往返时间应为 20ms 左右，接口速度和双工应分别为“1000MB / s”和“Full”。

149.1.4。解析度

在确定活动的以太网适配器速度不正确之后，我们使用ifenslave(8)命令使备用接口成为活动接口，从而立即提高了 MapReduce 的性能，并使网络吞吐量提高了 10 倍：

在下一次数据中心之旅中，我们确定线路速度问题最终是由更换的坏网线引起的。

149.2。案例研究＃2（2012 年绩效研究）

调查结果自我描述“我们不确定什么是错的，但似乎很慢”的问题。 http://gbif.blogspot.com/2012/03/hbase-performance-evaluation-continued.html

149.3。案例研究＃3（2010 年绩效研究））

从 2010 年开始对一般集群性能的调查结果。虽然这项研究是在较旧版本的代码库上进行的，但这种写法在方法方面仍然非常有用。 http://hstack.org/hbase-performance-testing/

149.4。案例研究＃4（max.transfer.threads 配置）

配置max.transfer.threads（以前称为xcievers）并诊断错误配置错误的案例研究。 http://www.larsgeorge.com/2012/03/hadoop-hbase-and-xceivers.html

另请参见 dfs.datanode.max.transfer.threads 。