自己弄个网站,中国关键词官网,最火的app排行榜前十名,wap网站源代码1. 异常突起
HBase 集群的某一个 RegionServer 的 CPU 使用率突然飙升到百分之百#xff0c;单独重启该 RegionServer 之后#xff0c;CPU 的负载依旧会逐渐攀上顶峰。多次重启集群之后#xff0c;CPU 满载的现象依然会复现#xff0c;且会持续居高不下#xff0c;慢慢地…1. 异常突起
HBase 集群的某一个 RegionServer 的 CPU 使用率突然飙升到百分之百单独重启该 RegionServer 之后CPU 的负载依旧会逐渐攀上顶峰。多次重启集群之后CPU 满载的现象依然会复现且会持续居高不下慢慢地该 RegionServer 就会宕掉慢慢地 HBase 集群就完犊子了。
2. 异常之上的现象
CDH 监控页面来看除 CPU 之外的几乎所有核心指标都是正常的磁盘和网络 IO 都很低内存更是充足压缩队列刷新队列也是正常的。 普罗米修斯的监控也是类似这样的就不贴图了。
监控指标里的数字只能直观地告诉我们现象不能告诉我们异常的起因。因此我们的第二反应是看日志。 企业微信截图
与此同时日志中还有很多类似这样的干扰输出。 后来发现这样的输出只是一些无关紧要的信息对分析问题没有任何帮助甚至会干扰我们对问题的定位。
但是日志中大量 scan responseTooSlow 的警告信息似乎在告诉我们HBase 的 Server 内部正在发生着大量耗时的 scan 操作这也许就是 CPU 负载高的元凶。可是由于各种因素的作用我们当时的关注点并没有在这个上面因为这样的信息我们在历史的时间段里也频繁撞见。
3. 初识 arthas
监控和日志都不能让我们百分百确定 CPU 负载高是由哪些操作引起的我们用 top 命令也只能看到 HBase 这个进程消耗了很多 CPU就像下图看到的这样。 如果不做进一步分析你仍然不知道问题出现在 HBase 相关进程下的哪些执行线程。Java 中分析进程的命令可以使用 jstack 或 jstat gcutil 等。但是今天要介绍的主角不是这俩甚至不是 async-profiler而是 arthas。async-profiler 虽然也是一个很强大的工具但是 arthas 包含了它且功能更强大堪称神器。
arthas 很早以前就听说过起初以为它只能用来分析 WEB 应用例如 Spring Boot这两天仔细翻看其官方文档之后才觉得自己是多么的无知。arthas 的相关介绍和入门使用请参考其文档它的官方文档比任何第三方资料都详细和友好。
https://github.com/alibaba/arthas阿尔萨斯官方文档https://github.com/jvm-profiling-tools/async-profiler
4. 用 arthas 来分析 HBase 的异常进程
4.1 运行 arthas
java -jar /data/arthas/arthas-boot.jar --target-ip 0.0.0.0
--target-ip 默认 127.0.0.1此处赋值为 0.0.0.0 是为了使用 webconsole
4.2 arthas 运行成功的界面 命令 top 定位到的异常的 HBase 进程 ID 是 1214该进程就是 HRegionServer 的进程。输入序号 1回车就进入了监听该进程的命令行界面。
4.3 dashboard 运行 dashboard 命令回车就可以查看该进程占用资源的总体情况可以从图中看到ID 为 59 的线程占用的 CPU 最高。
4.4 thread 输入 thread 命令回车查看该进程下所有线程的执行情况。
4.5 thread -n 3 输出资源占用前三名的线程。
4.6 thread -n 3 -i 5000 单位时间为 5 秒内资源占用前三名的线程。
4.7 使用async-profiler生成火焰图
生成火焰图的最简单命令。
profiler start
隔一段时间大概三十秒。
profiler stop 在 web console 里查看。 关于火焰图的入门级知识
查看 jvm 进程 cpu 火焰图工具。
火焰图里很清楚地定位到 CPU 时间占用最高的线程是绿框最长的那些线程也就是 scan 操作。
5. scan 操作引起的 CPU 负载过高
通过以上的进程分析我们最终可以确定scan 操作的发生导致 CPU 负载很高。我们查询 HBase 的 API 基于 happybase 封装而成https://happybase.readthedocs.io/en/latest/
其实常规的 scan 操作是能正常返回结果的发生异常查询的表也不是很大所以我们排除了热点的可能。抽象出来业务方的查询逻辑是
from happybase.connection import Connection
import time
start time.time()
con Connection(hostip, port9090, timeout3000)
table con.table(table_name)
try:res list(table.scan(filterPrefixFilter(273810955|),row_start\x0f\x10R\xca\xdf\x96\xcb\xe2\xad7$\xad9khE\x19\xfd\xaa\x87\xa5\xdd\xf7\x85\x1c\x81ku ^\x92k,limit3))
except Exception as e:pass
end time.time()
print timeout: %d % (end - start)
PrefixFilter 和 row_start 的组合是为了实现分页查询的需求row_start 的一堆乱码字符是加密的一个 user_id里面有特殊字符。日志中看到所有的耗时查询都有此类乱码字符的传参。于是我们猜想查询出现的异常与这些乱码字符有关。
但是后续测试复现的时候又发现。
# 会超时res list(table.scan(filterPrefixFilter(273810955|),row_start27, limit3))# 不会超时res list(table.scan(filterPrefixFilter(273810955|),row_start27381095, limit3))
也就是即使不是乱码字符传参filter 和 row_start 组合异常也会导致 CPU 异常的高row_start 指定的过小小于前缀数据扫描的范围估计就会变大类似触发了全表扫描CPUload 势必会变大。
6. 频繁创建连接或使用线程池造成 scan 线程持续增长
我们操作 HBase 的公共代码是由 happybase 封装而成其中还用到了 happybase 的线程池在我们更深入的测试中又发现了一个现象当我们使用连接池或在循环中重复创建连接时然后用 arthas 监控线程情况发现 scan 的线程会很严重测试代码如下
6.1 连接在循环外部创建重复使用
from happybase.connection import Connection
import time
con Connection(hostip, port9090, timeout2000)
table con.table(table)
for i in range(100):try:start time.time()res list(table.scan(filterPrefixFilter(273810955|),row_start\x0f\x10R\xca\xdf\x96\xcb\xe2\xad7$\xad9khE\x19\xfd\xaa\x87\xa5\xdd\xf7\x85\x1c\x81ku ^\x92k,limit3))except Exception as e:passend time.time()print timeout: %d % (end - start)
程序开始运行时可以打开 arthas 进入到 HRegionServer 进程的监控运行 thread 命令查看此时的线程使用情况 小部分在运行大部分在等待。此时CPU 的负载情况 6.2 循环在内部频繁创建然后使用
代码如下
from happybase.connection import Connection
import time
for i in range(100):try:start time.time()con Connection(hostip, port9090, timeout2000)table con.table(table)res list(table.scan(filterPrefixFilter(273810955|),row_start\x0f\x10R\xca\xdf\x96\xcb\xe2\xad7$\xad9khE\x19\xfd\xaa\x87\xa5\xdd\xf7\x85\x1c\x81ku ^\x92k,limit3))except Exception as e:passend time.time()print timeout: %d % (end - start)
下图中可以看到开始 RUNNING 的线程越来越多CPU 的消耗也越来越大。 此时 CPU 的使用情况由刚才的较为平稳陡然上升 6.3 连接池的方式访问 HBase
CPU 被之前的实验拉高重启下集群使 CPU 的状态恢复到之前平稳的状态。然后继续我们的测试测试代码
没有超时时间
from happybase import ConnectionPool
import time
pool ConnectionPool(size1, hostip, port9090)
for i in range(100):start time.time()try:with pool.connection(2000) as con:table con.table(table)res list(table.scan(filterPrefixFilter(273810955|),row_start\x0f\x10R\xca\xdf\x96\xcb\xe2\xad7$\xad9khE\x19\xfd\xaa\x87\xa5\xdd\xf7\x85\x1c\x81ku ^\x92k,limit3))except Exception as e:passend time.time()print timeout: %d % (end - start)
如果不指定超时时间会只有一个线程持续运行因为我的连接池设置为 1。 CPU 的负载也不是太高如果我的连接池设置的更大或者我的并发加大那么这些耗时 scan 的线程应该会更多CPU 使用率也会飙升。 指定超时时间
from happybase import ConnectionPool
import time
pool ConnectionPool(size1, hostip, port9090, timeout2000)
for i in range(100):start time.time()try:with pool.connection(2000) as con:table con.table(table)res list(table.scan(filterPrefixFilter(273810955|),row_start\x0f\x10R\xca\xdf\x96\xcb\xe2\xad7$\xad9khE\x19\xfd\xaa\x87\xa5\xdd\xf7\x85\x1c\x81ku ^\x92k,limit3))except Exception as e:passend time.time()print timeout: %d % (end - start)
此次测试中我指定了连接池中的超时时间期望的是连接超时及时断开继续下一次耗时查询。此时服务端处理 scan 请求的线程情况 服务端用于处理 scan 请求的 RUNNING 状态的线程持续增长并耗费大量的 CPU。 7. hbase.regionserver.handler.count 参考大神的博客以及自己对这个参数的理解每一个客户端发起的 RPC 请求读或写发送给服务端的时候服务端就会有一个线程池专门负责处理这些客户端的请求这个线程池可以保证同一时间点有 30 个线程可运行剩余请求要么阻塞要么被塞进队列中等待被处理scan 请求撑满了服务端的线程池大量的耗时操作把 CPU 资源消耗殆尽其余常规的读写请求也势必大受影响慢慢集群就完犊子了。
8. 控制 scan 请求占用很小的队列
首先这个 hbase.regionserver.handler.count 的参数不能被调小如果太小集群并发高时读写延时必高因为大部分请求都在排队。理想情况是读和写占用不同的线程池在处理读请求时scan 和 get 分别占用不同的线程池实现线程池资源隔离。如果是我的话第一反应可能也会简单、粗略地搞仨线程池写线程池get 线程池、scan 线程池。scan 线程池分配很小的核心线程让其占用很小的资源限制其无限扩张。但是真实的情况是这样吗暂时我还没仔细研究源码HBase 提供了如下参数可以满足读写资源分离的需求。以下内容摘自 HBase 官网文档翻译为谷歌翻译。https://hbase.apache.org/2.1/book.html
hbase.regionserver.handler.count
描述
在RegionServer上旋转的RPC侦听器实例数。主机将相同的属性用于主机处理程序的计数。过多的处理程序可能适得其反。使它成为CPU计数的倍数。如果大多数情况下是只读的则处理程序计数接近cpu计数的效果很好。从两倍的CPU计数开始然后从那里进行调整。
默认
30
hbase.ipc.server.callqueue.handler.factor
描述
确定呼叫队列数量的因素。值为0表示在所有处理程序之间共享一个队列。值为1表示每个处理程序都有自己的队列。
默认
0.1
hbase.ipc.server.callqueue.read.ratio
描述
将呼叫队列划分为读写队列。指定的间隔应在0.0到1.0之间将乘以呼叫队列的数量。值为0表示不拆分呼叫队列这意味着读取和写入请求都将被推送到同一组队列中。小于0.5的值表示读队列少于写队列。值为0.5表示将有相同数量的读取和写入队列。大于0.5的值表示将有比写队列更多的读队列。值1.0表示除一个队列外的所有队列均用于调度读取请求。示例给定呼叫队列的总数为10读比率为0表示10个队列将包含两个读/写请求。read.ratio为0.3表示3个队列将仅包含读取请求而7个队列将仅包含写入请求。read.ratio为0.5表示5个队列仅包含读取请求而5个队列仅包含写入请求。read.ratio为0.8表示8个队列将仅包含读取请求而2个队列将仅包含写入请求。read.ratio为1表示9个队列将仅包含读取请求而1个队列将仅包含写入请求。
默认
0
hbase.ipc.server.callqueue.scan.ratio
描述
给定读取呼叫队列的数量根据呼叫队列总数乘以callqueue.read.ratio计算得出scan.ratio属性会将读取呼叫队列分为小读取队列和长读取队列。小于0.5的值表示长读队列少于短读队列。值为0.5表示将有相同数量的短读和长读队列。大于0.5的值表示长读取队列比短读取队列多。值为0或1表示使用相同的队列进行获取和扫描。示例假设读取呼叫队列的总数为8则scan.ratio为0或1表示8个队列将同时包含长读取请求和短读取请求。scan.ratio为0.3表示2个队列将仅包含长读请求而6个队列将仅包含短读请求。scan.ratio为0.5表示4个队列将仅包含长读请求而4个队列将仅包含短读请求。scan.ratio为0.8表示6个队列将仅包含长读请求而2个队列将仅包含短读请求。
默认
0
这几个参数的作用官网解释的还挺详细按照其中的意思配置一定比例就可以达到读写队列get 和 scan 队列分离的目的但是调配参数后继续如上测试发现并不难控制 RUNNING 的线程的数量发现没毛用。
这里有一个疑问队列和我所理解的线程池直接到底是什么关系是否是一个东西这个之后需要观其源码窥其本质。
9. 总结
啰啰嗦嗦总算把定位问题的整个过程记录了下来其实文字描述的还不算很详尽只是尽可能还原当时的场景和梳理问题的大体思维流程免得以后遗忘同时也期望各位同行能从我这里受到点启发期间也受到了不少大神的提点在此也特别感谢各方大佬的帮助。 原文链接 本文为阿里云原创内容未经允许不得转载。
