用jstack发现的一例hbase region server线程死锁

最新推荐文章于 2022-07-09 16:08:20 发布
最新推荐文章于 2022-07-09 16:08:20 发布
阅读量2.3k 收藏 1
点赞数
分类专栏： hbase hadoop
本文详细阐述了在升级Hadoop集群过程中遇到的HBase偶尔无法读写的问题，通过jstack工具发现并分析了由logRoller和HLog.syncer线程引起的死锁现象。文章深入探讨了HBase的WAL机制及其在数据持久化过程中的作用，揭示了死锁的根本原因，并指出是由于集群升级后磁盘I/O增加，以及大型任务执行导致的HLog.syncer异常引发了此问题。最终，文章指出已知的社区修复方案，以及通过优化集群配置来减少磁盘I/O压力作为预防措施。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

最近在升级hadoop集群的过程中，hbase偶尔出现无法读写的情况，看region server进程并没有挂掉，于是用jstack看下是什么情况：

Found one Java-level deadlock:
=============================
'IPC Server handler 127 on 60020':
  waiting to lock monitor 0x00007fa185def330 (object0x000000057becf198, a java.lang.Object),
  which is held by 'IPC Server handler 21 on 60020'
'IPC Server handler 21 on 60020':
  waiting to lock monitor 0x00007fa1984780b0 (object0x000000057b96e178, a java.lang.Object),
  which is held by 'regionserver60020.logRoller'
'regionserver60020.logRoller':
  waiting to lock monitor 0x00007fa185def330 (object0x000000057becf198, a java.lang.Object),
  which is held by 'IPC Server handler 21 on 60020'
 
Java stack information for the threads listed above:
===================================================
'IPC Server handler 127 on 60020':
        at org.apache.hadoop.hbase.regionserver.wal.HLog.syncer(HLog.java:1305)
        - waiting to lock <0x000000057becf198> (a java.lang.Object)
        at org.apache.hadoop.hbase.regionserver.wal.HLog.sync(HLog.java:1460)
        at org.apache.hadoop.hbase.regionserver.HRegion.doMiniBatchMutation(HRegion.java:2231)
        at org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:1968)
        at org.apache.hadoop.hbase.regionserver.HRegionServer.multi(HRegionServer.java:3428)
        at sun.reflect.GeneratedMethodAccessor35.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.apache.hadoop.hbase.ipc.WritableRpcEngine$Server.call(WritableRpcEngine.java:364)
        at org.apache.hadoop.hbase.ipc.HBaseServer$Handler.run(HBaseServer.java:1389)
'IPC Server handler 21 on 60020':
 at org.apache.hadoop.hbase.regionserver.wal.HLog.syncer(HLog.java:1314)
        - waiting to lock <0x000000057b96e178> (a java.lang.Object)
        - locked <0x000000057becf198> (a java.lang.Object)
        at org.apache.hadoop.hbase.regionserver.wal.HLog.sync(HLog.java:1460)
        at org.apache.hadoop.hbase.regionserver.HRegion.doMiniBatchMutation(HRegion.java:2231)
        at org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:1968)
        at org.apache.hadoop.hbase.regionserver.HRegionServer.multi(HRegionServer.java:3428)
        at sun.reflect.GeneratedMethodAccessor35.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.apache.hadoop.hbase.ipc.WritableRpcEngine$Server.call(WritableRpcEngine.java:364)
        at org.apache.hadoop.hbase.ipc.HBaseServer$Handler.run(HBaseServer.java:1389)
'regionserver60020.logRoller':
        at org.apache.hadoop.hbase.regionserver.wal.HLog.syncer(HLog.java:1305)
        - waiting to lock <0x000000057becf198> (a java.lang.Object)
        at org.apache.hadoop.hbase.regionserver.wal.HLog.syncer(HLog.java:1283)
        at org.apache.hadoop.hbase.regionserver.wal.HLog.sync(HLog.java:1456)
        at org.apache.hadoop.hbase.regionserver.wal.HLog.cleanupCurrentWriter(HLog.java:876)
        at org.apache.hadoop.hbase.regionserver.wal.HLog.rollWriter(HLog.java:657)
        - locked <0x000000057b96e178> (a java.lang.Object)
        at org.apache.hadoop.hbase.regionserver.LogRoller.run(LogRoller.java:94)
        at java.lang.Thread.run(Thread.java:662)
 
Found 1 deadlock.

显然，这是logRoller和HLog.syncer两个线程发生了死锁。

在Hbase中，采用WAL(Write Ahead Log)的方式来保证数据不丢失。一个Region Server对应一个HLog，任何数据都是先写HLog，然后才真正的写MemStore。HLog文件有个轮转的过程，当达到默认大小（一般是block size * 0.95）就会写一个新的HLog文件，logRoller线程就是做这个事情的。而buffer中的数据每隔一秒钟会写一次HLog文件，这个是HLog.syncer线程负责的。logRoller和HLog.syncer进程不能同时进行，不然会导致数据问题，于是就需要通过锁来进行互斥了。

查看了下代码，是在HLog.syncer往HDFS写文件发生IO Exception时会触发死锁。一番google后发现是我们集群使用的hbase 0.94.1版本的一个bug，目前在社区已经修复了：https://issues.apache.org/jira/browse/HBASE-7728。

其实频繁触发Hbase的这个bug主要还是因为这次hadoop集群升级引起的。由于hadoop集群升级后导致集群的diskIO变高，加上有些大的任务在测试，HLog.syncer发生IO Exception的几率就更高了，所以RS假死就更频繁了。

HBase性能优化指南
AI天才研究院
08-03 1099
随着互联网的快速发展，海量数据的产生、收集、处理、分析等过程越来越复杂，传统的关系型数据库(RDBMS)已经无法适应如此海量的数据。因此，NoSQL系统(如HBase)逐渐取代了RDBMS成为新的主要数据库。同时，HBase也面临着越来越多的应用场景，包括存储时序数据、实时查询分析等，这些应用都对数据库的性能提出了更高的要求。为了满足HBase在各种情况下的性能需求，作者推荐了以下五个方面的性能优化策略：1.选择合适的压缩算法：目前，HBase支持snappy、zlib、lzo、lz4等几种压缩算法。
大数据领域中Zookeeper的核心原理深度剖析
AI天才研究院
05-22 1115
在大数据技术栈中，分布式系统面临节点故障、状态同步、资源竞争等复杂协调问题。Zookeeper作为Hadoop、Kafka、HBase等核心组件的底层协调引擎，其设计原理直接影响整个集群的稳定性。本文聚焦Zookeeper的核心技术架构，包括数据模型设计、集群管理机制、一致性协议实现等，结合具体代码示例和数学分析，揭示其底层工作原理。背景知识体系构建核心概念与架构解析算法原理与协议实现数学模型与一致性分析实战案例与生态整合未来趋势与挑战分析ZNode。
HBase 异步查询导致的死锁和zookeeper通信中断问题追踪与总结［非技术］
weixin_30859423的博客
12-13 179
机房T和机房Y共十台前端机，Y机房请求量是T的两倍，主要用于数据查询，开始问题是Y机房tomcat 相继僵死 1） tomcat僵死处理步骤 a 检查代码，发现read through后，没有把DB数据写到缓存，增加回写代码；但单台机器每秒请求也就几十条，HBase压力很小，最终发现无效。 b 检查代码，认为跟运行几个月的动态代码在HBase使用上完全一致，所以认为业务代码层没有问题；打印堆...
HBaseAPI在执行时卡住不动，程序死锁
V0_fly的博客
08-08 3011
一般程序有问题都可以通过日志或者抛出的异常找到原因，但是今天碰到这个问题让我这个新手感到非常棘手，因为程序没有报错，日志也没有显示错误，就卡死不动，最后在老师的帮助下解决了问题。 我搭建的是分布式hbase，而不是伪分布式的，而问题就出在JAVA程序中我用同伪分布式一样的配置方法配置分布式，代码如下： conf.set("hbase.zookeeper.quorum", "master:218
HBase行锁
weixin_30609331的博客
11-26 213
1 行锁简介 在事务特性方面，hbase只支持单row的事务，不能保证跨row(cross-row)的事务。hbase通过行锁来实现单row事务。客户端进行操作时，可以显式对某一个行加锁，但是大部分情况下是没有必要的，因为如果没有显式的加行锁，hbase在内部会默认的加行锁。为了描述方便，用户显式加的行锁简称为显式行锁。 源码1：客户端使用显式行锁的示例代码 HTabl...
[HBase]abort引发的死锁
吊丝码农
03-26 835
今天在HBase群里碰到一个客户端死锁问题，堆栈如下 Java stack information for the threads listed above: =================================================== "KVQueueService-Handler-2-EventThread": at org.apache.h...
a Java-level deadlock example
fanrey123的博客
05-25 227
Found one Java-level deadlock: ============================= "StartStopServicePool-5 - 5165": waiting to lock monitor 0x0816cc20 (object 0xb37eb908, a sun.misc.Launcher$AppClassLoader), which ...
【HBase实战案例篇】社区与生态系统：HBase在大数据领域中的生态系统贡献和案例研究
![【HBase实战案例篇】社区与生态系统：HBase在大数据领域中的生态系统贡献和案例研究]...HBase是一个开源的非关系型分布式数据库（NoSQL），它被设计用来在商用硬件集群上提供对大规模数据集的随机
HBase集群监控与维护：专家级指南，打造无忧大数据环境
作为NoSQL数据库的一种，HBase因其可扩展性和高性能而被广泛应用于大数据存储解决方案中。然而，随着集群规模的增长，监控和维护工作变得复杂且至关重要，它们有助于确保数据的可用性、一致性和性能最优化。 我们将...
【HBase故障诊断】：快速响应与系统稳定性提升的终极指南
本文首先概述了HBase故障诊断的基本概念和重要性，接着深入探讨了HBase的基础理论与架构，包括数据模型、存储机制、架构组件及其性能优化原则。第三章详细介绍了HBase故障诊断的工具与方法，包括内置工具和第三方...
Java并发：隐藏的线程死锁
qi20088的专栏
04-08 943
许多程序员都熟悉Java线程死锁的概念。死锁就是两个线程一直相互等待。这种情况通常是由同步或者锁的访问(读或写)不当造成的。 Found one Java-level deadlock: ============================= "pool-1-thread-2":   waiting to lock monitor 0x0237a
Java DeadLock
Dave_lzw的博客
06-15 734
public class TestDeadLock implements Runnable{ public int flag = 1; static Object o1 = new Object(),o2 = new Object(); public void run(){ System.out.println("flag = "+flag); if(flag==1){ syn
hbase本机测试卡死
阿达丶
08-27 344
无异常 只有log4j SLF4J: Class path contains multiple SLF4J bindings. SLF4J: Found binding in [jar:file:/E:/jar/hbasejars/log4j-slf4j-impl-2.1.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found bin...
记录一次真实的Java服务死锁问题
weixin_39919140的博客
03-09 616
项目启动死锁问题的排查和解决
定位Java线程死锁
windfbi
06-16 303
文章目录制造死锁分析死锁查找PID线程栈分析 制造死锁 死锁的原因通常是线程之间持有对方等待获取的锁，线程一直停留在BLOCKED状态。照此思路可以人为制造死锁如下： package com.jk.iw.deadlock; /** * @Description: * @Author alvin * @Date 2021/6/15 3:44 PM * @Version 1.0 */ public class DeadLockFBI extends Thread { private Stri
java deadlock怎么解决_Java 出现deadlock, 但被锁的对象为
weixin_36150816的博客
02-26 511
环境：linux redhat 2.6.18-194.el5JDK: 1.6.0_27 x64btrace版本: 1.2.3tomcat:7.0.22场景:把btrace-agent加载到tomcat中启动, 并且只加载一个Btrace脚本文件，启动时出现死锁，而且是每次必现。Thread dump如下:Found one Java-level deadlock:==============...
Java 死锁分析
Logicr的博客
07-09 383
用两个线程，两个对象，线程a锁住obj1然后再去锁obj2，线程b锁住obj2然后去锁obj1。这时候线程a持有obj1的锁，线程b持有obj2的锁，当等待时间结束，就会互相等待锁，形成死锁。 输出 查看死锁 执行 输出 输出分析： 可以看到有一个deadlock，线程信息Thread-1锁住了0x000000076ae31540，等待0x000000076ae31530的锁，而线程Thread-0 锁住 ，等待0x000000076ae31540的锁，相互等待对方释...
Java并发：隐藏线程死锁
最佳 Java 编程
05-14 341
大多数Java程序员熟悉Java线程死锁概念。 它本质上涉及2个线程，它们彼此永远等待。 这种情况通常是平面（同步）或ReentrantLock（读或写）锁排序问题的结果。 Found one Java-level deadlock: ============================= "pool-1-thread-2": waiting to lock monitor 0x0...
java并发程序死锁检测_Java并发：隐藏的线程死锁
weixin_42337065的博客
03-02 508
许多程序员都熟悉Java线程死锁的概念。死锁就是两个线程一直相互等待。这种情况通常是由同步或者锁的访问(读或写)不当造成的。Found one Java-level deadlock:============================="pool-1-thread-2":waiting to lock monitor 0x0237ada4 (object 0x272200e8, a java...
如何用`jstack`诊断Java线程死锁？
最新发布
05-28
<think>好的，我现在需要回答用户的问题：“如何使用jstack诊断Java线程死锁”。用户之前已经询问过Java多线程程序卡住的原因，现在想具体了解如何用jstack工具来检测死锁。首先，我需要回忆之前提供的关于死锁的部分，其中提到使用jstack生成线程转储来查看锁的情况。用户现在希望详细步骤，所以需要分步骤说明操作流程。接下来，参考用户提供的引用内容。引用[1]中提到jstack可以生成线程转储，并且使用-l参数显示死锁信息。引用[2]同样说明jstack用于查找死锁和分析线程堆栈。需要结合这些信息，给出具体的命令和示例。 用户可能不太清楚如何获取jpid，所以需要提到使用jps命令来查找Java进程ID。然后，执行jstack命令，并解释如何分析输出结果中的死锁信息。例如，在输出中搜索“deadlock”或者“Foundone Java-level deadlock”，并展示示例代码块。 还要注意用户提到的系统级指令，比如数学表达式用$...$，但这个问题可能不太涉及数学公式，所以可能不需要。但需要确保中文回答，结构清晰，分步骤说明，并添加引用标识。另外，用户可能需要诊断死锁的具体例子，比如两个线程互相持有锁的情况，所以在步骤中应该包括如何在线程转储中识别这种情况。可能还需要提到如何检查线程状态，如BLOCKED，以及锁的持有者和等待者。 最后，生成相关问题，比如如何预防死锁、其他诊断工具等，确保相关问题与主题相关，并引导用户进一步学习。</think>### 使用 jstack 诊断 Java 线程死锁的方法 #### 1. 获取 Java 进程 ID (PID) ```bash jps -l ``` 输出示例： ```text 12345 com.example.MainApplication 67890 sun.tools.jps.Jps ``` 记录目标程序的 PID（如 `12345`）[^1]。 #### 2. 生成线程转储文件 ```bash jstack -l 12345 > thread_dump.txt ``` `-l` 参数会显示锁的持有和等待信息[^2]。 #### 3. 分析死锁特征 在 `thread_dump.txt` 中搜索以下关键词： - **`deadlock`**：系统检测到的死锁标识 - **`BLOCKED`**：线程阻塞状态 - **`waiting to lock <0x0000000712345678>`**：等待锁的线程 - **`holding lock <0x0000000712345678>`**：持有锁的线程 #### 4. 识别死锁示例 ```text Found one Java-level deadlock: ============================= "Thread-1": waiting to lock monitor 0x00007f88d8001234 (object 0x0000000712345678) which is held by "Thread-0" "Thread-0": waiting to lock monitor 0x00007f88d8005678 (object 0x0000000712345abc) which is held by "Thread-1" ``` 此示例显示两个线程互相持有对方需要的锁[^2]。 #### 5. 关键数据解析 - **锁标识符**：`0x0000000712345678` 表示内存中的锁对象地址 - **线程状态**：`BLOCKED` 表示线程因锁竞争被阻塞 - **堆栈跟踪**：显示线程在哪个代码行等待锁（需结合源代码） #### 6. 诊断流程图 $$ \begin{cases} \text{运行程序} \rightarrow \text{发现卡顿} \\ \downarrow \\ \text{jps获取PID} \rightarrow \text{jstack生成转储} \\ \downarrow \\ \text{分析死锁特征} \rightarrow \text{定位冲突锁} \\ \downarrow \\ \text{修改同步逻辑} \rightarrow \text{验证修复} \end{cases} $$ #### 7. 高级技巧 - **连续抓取**：间隔 5 秒抓取 3 次转储，观察锁状态变化 ```bash for i in {1..3}; do jstack -l 12345 > dump_$i.txt; sleep 5; done ``` - **结合代码**：通过 `synchronized` 关键字或 `ReentrantLock` 的调用位置验证锁竞争点
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值