内核futex的BUG导致程序hang死问题排查

2019/01/14 23:05
阅读数 337

 

https://mp.weixin.qq.com/s/sGS-Kw18sDnGEMfQrbPbVw

内核futex的BUG导致程序hang死问题排查

原创: 王领先 58架构师 今天
 

近日,Hadoop的同学反映,新上的几台机器上的java程序出现hang死的现象,查看系统的message记录,发现一些内存方面的错误输出,怀疑是内存不足导致java程序hang死在gc的过程中。经排查发现即使是在内存充足的情况下也会出现程序hang死的现象。

 

我们又发现只有这批新上的机器才出现hang死的问题,之前老机器上一直很正常。排查后发现在老机器上有一个监控脚本,每隔一段时间就会用jstack查看一下java程序的状态。关了监控脚本后,老机器也出现了hang死的问题。最后我们发现使用jstack、pstack都可以将原来hang死的程序刷活。

 

后来DBA的同学也反映,他们的xtrabackup程序也出现了hang死的问题,最后我们使用GDB对这个备份程序分析后发现,问题的原因出现在内核的一个BUG上。

结论

出现问题的机器上的Linux内核都是linux 2.6.32-504版本,这个版本存在一个futex的BUG。

参见:

https://github.com/torvalds/linux/commit/76835b0ebf8a7fe85beb03c75121419a7dec52f0

这个BUG会导致非共享锁的程序体会陷入无人唤醒的等待状态,造成程序hang死。

 

触发这个BUG需要具备以下几个条件:

• 内核是2.6.32-504.23.4以下的版本

• 程序体需要使用非共享锁的锁竞争

• CPU需要有多核,且需要有CPU缓存

满足以上条件就有概率触发这个程序hang死的BUG。

 

解决方案就是升级到 2.6.32-504.23.4或更高版本来修复此BUG。

 

下面我们来看一下,是如何断定问题是由这个BUG引起的。

原理分析

1. 首先要拿到进程ID

我们要分析的xtrabackup程序的PID是715765

 

2. 看一下内核调用栈

cat /proc/715765/*/task/stack

发现大多数线程在停在 futex_wait_queue_me 这个内核函数中。

这个函数使当前线程主动释放CPU进入等待状态,若没有被唤醒,就一直停在这个函数中。

也就是说,现在大多数线程都在等其他资源释放锁,下面我们就需要到用户态下分析,他们到底在等待什么锁。

3. 分析用户态代码

gdb attach 715765

对于这种程序hang死的问题,最好的工具还是gdb,附加到程序上,来获取的实时状态信息。

 

3.1 查看线程信息

首先先看一下在用户态中线程的状态。

可以看到线程大体有两类等待, pthread_cond_wait 和 __lll_lock_wait。

pthread_cond_wait是线程在等待一个条件成立,这个条件一般由另一个线程设置;

__lll_lock_wait是线程在等另一个线程释放锁,一般是抢占锁失败,在等其他线程释放这个锁。

 

3.2 查看每个线程信息

看到大体有三类线程:

• 拷贝线程:data_copy_thread_func

• 压缩线程:compress_wokrer_thread_func

• IO线程:io_handler_thread

为了弄明白这些线程的作用,我们可以先了解下xtrabackup的工作原理。

 

3.3 工作原理说明

mysql数据库备份中的一个工作就是将数据库文件拷贝,为节省空间,可以通过参数来设置开启压缩。

在做实际分析前,我们先梳理一遍启用压缩后,拷贝线程的业务逻辑:

• 拷贝线程会把文件分成多个小块,喂给压缩线程

• 在喂之前,需要通过一个控制锁来获取这个压缩线程的控制权

• 喂完后,会发送一个条件信号来通知压缩线程干活

• 然后就依次等每个压缩线程将活干完

• 每等到一个压缩线程干完活,就将数据写到文件中,然后释放这个压缩线程控制锁

下面我们看一个具体的拷贝线程,我们从第1个拷贝线程开始,也就是2#线程。

 

3.4 拷贝线程2# 锁分析

拷贝线程2# hang死的位置 是  在给第1个压缩线程发送数据前,加ctrl_mutex锁的地方

它在等其owner 715800 释放,而715800 对应的是7#线程

 

 

3.5 拷贝线程 7# 锁分析

我们看到7# 线程hang死的位置与2号线程是相同,不同的是 它是卡在第3个压缩线程上,且其ctrl_mutex的owner为空。也就是说没有与其竞争的线程,它自己就一直在这等。

虽然这个现象很奇怪,但可以确定这不是死锁问题导致的。一般来讲只能是内核在释放锁时出现问题才会出现这种空等的情况。

为了更完整的还原出当时的场景,我们需要分析一下到底都有谁有可能释放压缩线程的控制锁。 

 

3.6 拷贝线程控制锁怎么释放

ctrl_mutex对应的是压缩线程一个控制锁,拥有这个锁才能对压缩线程做相应的操作

在xtrabackup中,大体有四个地方释放这个锁:

1. 创建压缩线程时,会初始化这个锁,并通过这个锁启动线程进入主循环

2. 压缩线程在运行时, 会使用这个锁设置启动状态(与上面的创建线程对应)

3. 拷贝线程会在往压缩线程放原始数据时,把持这个锁,在从压缩线程拿完数据后,释放对应锁

4. 销毁压缩线程后,会释放上面相关的锁

查看日志我们看到,日志是停在一个压缩文件的过程中,且上面完成了多次文件的压缩操作;

所以,可以排除上面的1、2、4这三种情况;

 

那么我们可以再做出下面的假设:

前面有一个拷贝线程,取完了几个压缩线程的压缩结果,释放了这几个压缩线程;

这时,7#拷贝线程正好拿到了1、2两个压缩线程的控制锁,往里放完数据后,开始要拿第3个压缩线程的控制锁;

这时前一个拷贝线程并没有释放,于是7#只好在加锁处等待;

但当前一个拷贝线程释放第3个压缩线程锁的时候,内核并没有通知到7#线程,造成其一直在等待。

而7#线程等待的过程中,也不会释放其他已把持的压缩线程的锁,造成其他拷贝线程一直等待其释放,最后导致整个进程夯死。

到此我们大概还原了程序hang死的场景,目前来讲嫌疑最大的就是内核出现了问题,而当前内核版本正好有一个futex的BUG,我们来具体看一下这个BUG是否是导致程序hang死的元凶。

 

4. 内核的futex的BUG分析

先看一下内核futex中的这个BUG,其实很简单,就是少加了两行代码;严格点说是在非共享锁分支上少加了一个mb。

mb又是什么呢?mb的作用将上下两部分代码做一个严格的分离,一般叫屏障,主要有两种屏障:

• 优化屏障:当gcc编译器从O2级别的优化开始就会对指令进行重排,而mb会在其宏上加一个volatile关键字来告诉编译器禁止与其他指令重排。

• 内存屏障:现在CPU通常是并行的执行若干条指令,具可能重新安排内存访问的次序,这种重排或乱序可以极大地加速程序运行,但也会导致一些需要数据同步的场景导致读到脏数据。而mb会使用mfence汇编指令告诉CPU,必须要把前面的指令执行完,才能执行其下面的指令,保证操作同步。

那不加这个mb 会造成什么实际影响呢?我们来看futex_wake函数的代码:

futex_wake函数中会查看hb变量里有没有需要被唤醒的锁,如果没有就不做唤醒操作。

若没加 mb,将导致其获取的数据不一致,有机率将实际有锁在等待而误当成没锁在等待,造成该唤醒的锁,错失唯一一次被唤醒的机会,导致其一直处在等待状态,最终导致程序夯死!

下面我们要确定一件事情就是,当前程序是否命中了这个BUG,也就是说当前锁是否是非共享锁。我们查看pthread的代码,可以看到__kind的值决定了其传给内核的锁是共享还是非共享的。

 

通过gdb可以看到,__kind的值为0,一定是非共享锁;

通过上面的分析,我们基本可以得出是内核BUG导致xtracbackup程序的hang死。

最后我们将内核升到了2.6.32-504.23.4,发现xtrabackup程序能正常运行,然后我们对hadoop服务器内核也做了升级,发现hang死问题也解决了。

 结语

通过上面的分析过程,我们可以发现gdb对这种需要实时分析的问题场景特别契合,但一般用来调度用户态的代码,内核态的相关信息可能用systemtap等工具更方便一些。

 

此外,还有一个问题令人困惑,就是为什么使用pstack、jstack、gdb或SIGSTP+SIGCON信号能唤醒hang死的程序?

这里要说明的一点就是jstack、gdb、pstack的原理都是通过内核的SIGTRAP等一系列调试信号来,抓取信息或调试程序的;

 

所以,这个问题的本质是为什么信号能唤醒程序?

我们看到出现这种夯死现象的程序,大多线程都会停在 内核的 futex_wait_queue_me 这个函数处;而这个函数,使用 TASK_INTERRUPTIBLE 来设置自己的状态,表示自己主动想放弃CPU,但可以被中断、信号或其他程序唤醒;并在下面调用  schedule  内核调度方法,主动通知内核放弃自己的CPU。 

 

所以,我们从外界最简单的就是通过向其发送信号,来唤醒那些可能永远等待的线程,让程序跑起来。 

 

 

展开阅读全文
打赏
0
2 收藏
分享
加载中
更多评论
打赏
0 评论
2 收藏
0
分享
返回顶部
顶部