用 Arthas 神器来诊断 HBase 异常进程
作者 | 介龙平,英文名 leo,码农一枚
【Arthas 官方社区正在举行征文活动,参加即有奖品拿~点击投稿】
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(host='ip', port=9090, timeout=3000)
table = con.table("table_name")
try:res = list(table.scan(filter="PrefixFilter('273810955|')",row_start='\x0f\x10&R\xca\xdf\x96\xcb\xe2\xad7$\xad9khE\x19\xfd\xaa\x87\xa5\xdd\xf7\x85\x1c\x81ku ^\x92k',limit=3))
except Exception as e:pass
end = time.time()
print 'timeout: %d' % (end - start)
PrefixFilter 和 row_start 的组合是为了实现分页查询的需求,row_start 的一堆乱码字符,是加密的一个 user_id,里面有特殊字符。日志中看到,所有的耗时查询,都有此类乱码字符的传参。于是,我们猜想,查询出现的异常与这些乱码字符有关。
但是,后续测试复现的时候又发现。
# 会超时res = list(table.scan(filter="PrefixFilter('273810955|')",row_start='27', limit=3))# 不会超时res = list(table.scan(filter="PrefixFilter('273810955|')",row_start='27381095', limit=3))
也就是,即使不是乱码字符传参,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(host='ip', port=9090, timeout=2000)
table = con.table("table")
for i in range(100):try:start = time.time()res = list(table.scan(filter="PrefixFilter('273810955|')",row_start='\x0f\x10&R\xca\xdf\x96\xcb\xe2\xad7$\xad9khE\x19\xfd\xaa\x87\xa5\xdd\xf7\x85\x1c\x81ku ^\x92k',limit=3))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(host='ip', port=9090, timeout=2000)table = con.table("table")res = list(table.scan(filter="PrefixFilter('273810955|')",row_start='\x0f\x10&R\xca\xdf\x96\xcb\xe2\xad7$\xad9khE\x19\xfd\xaa\x87\xa5\xdd\xf7\x85\x1c\x81ku ^\x92k',limit=3))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(size=1, host='ip', port=9090)
for i in range(100):start = time.time()try:with pool.connection(2000) as con:table = con.table("table")res = list(table.scan(filter="PrefixFilter('273810955|')",row_start='\x0f\x10&R\xca\xdf\x96\xcb\xe2\xad7$\xad9khE\x19\xfd\xaa\x87\xa5\xdd\xf7\x85\x1c\x81ku ^\x92k',limit=3))except Exception as e:passend = time.time()print 'timeout: %d' % (end - start)
如果不指定超时时间,会只有一个线程持续运行,因为我的连接池设置为 1。
CPU 的负载也不是太高,如果我的连接池设置的更大,或者我的并发加大,那么这些耗时 scan 的线程应该会更多,CPU 使用率也会飙升。
指定超时时间
from happybase import ConnectionPool
import time
pool = ConnectionPool(size=1, host='ip', port=9090, timeout=2000)
for i in range(100):start = time.time()try:with pool.connection(2000) as con:table = con.table("table")res = list(table.scan(filter="PrefixFilter('273810955|')",row_start='\x0f\x10&R\xca\xdf\x96\xcb\xe2\xad7$\xad9khE\x19\xfd\xaa\x87\xa5\xdd\xf7\x85\x1c\x81ku ^\x92k',limit=3))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. 总结
啰啰嗦嗦总算把定位问题的整个过程记录了下来,其实文字描述的还不算很详尽,只是尽可能还原当时的场景和梳理问题的大体思维流程,免得以后遗忘,同时也期望各位同行能从我这里受到点启发,期间也受到了不少大神的提点,在此也特别感谢各方大佬的帮助。
Arthas 征文活动火热进行中
Arthas 官方正在举行征文活动,如果你有:
- 使用 Arthas 排查过的问题
- 对 Arthas 进行源码解读
- 对 Arthas 提出建议
- 不限,其它与 Arthas 有关的内容
欢迎参加征文活动,还有奖品拿哦~点击投稿
“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的公众号。”
用 Arthas 神器来诊断 HBase 异常进程相关推荐
- 进程异常行为-访问恶意下载源 解决方案_不要忽略服务器上的异常进程
在之前的文章中,我们看到了ADAudit Plus的用户行为分析(UBA)功能如何使管理员能够监视用户登录活动以识别受感染的帐户.ADAudit Plus中的UBA还可以帮助您跟踪成员服务器上的任何异 ...
- linux下隐藏root进程,宝塔面板隐藏彩蛋 – btkill.py:Linux异常进程专杀
无意中发现宝塔面板btkill.py这个文件,打开一开原来的是Linux异常进程专杀的文件,从来没注意过啊,大鸟看了下5.9版本和最新的6.9版本都有这个文件存在,难道是宝塔官方留给用户的彩蛋? 不管 ...
- qq音乐网络异常获取音乐失败_QQ音乐怎么诊断网络异常
QQ音乐软件给大家提供了海量的歌曲音乐,而且播放流畅不卡顿,音质也非常的好.想必还有不少朋友都不清楚QQ音乐怎么诊断网络异常,接下去就由兔叽下载站小编告诉大家解决辨别网络异常方法介绍吧,有需要解决这个 ...
- 服务器进程显示异常,查看服务器异常进程
查看服务器异常进程 内容精选 换一换 企业主机安全服务主要包含资产管理.漏洞管理.入侵检测.基线检查和网页防篡改功能.资产管理功能可深度扫描出主机中的账号.端口.进程.Web目录.软件信息和自启动任务 ...
- Self-organizing Maps及其改进算法Neural gas聚类在异常进程事件识别可行性初探
catalogue 1. SOM简介2. SOM模型在应用中的设计细节3. SOM功能分析4. Self-Organizing Maps with TensorFlow5. SOM在异常进程事件中自动 ...
- Arthas - 开源 Java 诊断工具
转载自 Arthas使用 Authas - 开源的java诊断工具 下载安装 authas是一个jar包,可以直接下载后运行 wget https://alibaba.github.io/artha ...
- Arthas(1):Java诊断工具Arthas入门教程
文章目录 前言 第一节 Arthas 能为你做什么? 第二节 环境准备 第三节 快速入门 1. 启动math-game 2. 启动arthas 3. 查看dashboard 4. 通过 thread ...
- Arthas研究笔记(Java诊断工具)
Java诊断工具-Arthas 使用场景 1.排查函数调用异常现象 2.热更新代码 3.动态更新应用Logger Level 4.获取Spring Context 命令列表 dashboard 显示当 ...
- linux c 调试 strace 诊断 调试程序 异常退出 崩溃
目录 strace是什么? strace能做什么? strace怎么用? strace问题定位案例 1.定位进程异常退出 2.定位共享内存异常 3. 性能分析 跟踪系统调用和信号 strace是什么? ...
最新文章
- 07/11/13 资料整理
- 实现线程安全的单例模式
- 你能排第几?2016互联网行业薪酬数据分析
- (JavaWeb)ServletContext对象
- Java基础之多态深入解析
- C#中使用SendMessage进行进程通信,可发送字符串,结构体(不能发送类类型)。
- android 动态获取全县_省市县 ------ 三级滚动(android)
- 20145313《信息安全系统设计基础》第7周学习总结
- 基于单片机的贪吃蛇游戏设计仿真
- 如何在linux下观看需vodplayer播放的电影
- win10 软路由_软路由和硬路由的区别分析
- 我的第一本社会心理学(part1)--社会心理学是研究个体和群体的社会心理、社会行为及其发展规律的科学
- 等额本息房贷月供计算
- ZBrush - 冰雪奇缘角色建模
- 什么样的人适合参加IT编程培训?
- spss基本总结——因子分析
- 查找读者姓名mysql_练习1.sql · 刘友亮/mysql第三次作业 - Gitee.com
- WINDOWS下SIP拨号的实现
- excel表格中如何设置下拉菜单
- 网络调度框架Retrofit2的使用与原理解析