Linux - Sim Wiki

最后修改人	sim
最后修改时间	2025-06-26 08:43:57
创建人	sim
创建时间	2023-02-23 16:02:55

该文档由 sim 创建于 2023-02-23 16:02:55 ， sim 在 2025-06-26 08:43:57 修改了该文档。

[TOCM]

##### 现场描述：

Linux系统load负载短时间飙升至10000+，硬件为dell-r640 系统为centos7.6 内核版本 3.10 64核CPU，内存512G，2个RAID5磁盘组

当时现场环境：
1. CPU负载 10% 左右
1. 内存消耗 67% 左右
1. iowait值偏高 40左右
1. vmstat显示r队列在5-10之间，b队列25-30之间，有明显阻塞现象
1. iostat显示当时磁盘读操作大量上升，写操作基本归0，IO读写延迟明显升高
1. 某个java进程CPU占用升高，进程状态边为D状态（disk sleep）
![size:00,1200](/storage/2023/02-23/8enNoAMYFxV54hjB2tfFTRaxhWOEQRQxfqZZhD8V.png)
1. 故障发生时内存cache/buffer被全部清空
1. sar -B 发现pgscand/s数值对比平时升高非常多
1. message中发现有 task jbd2/sda-8:1343 blocked for more than 120 seconds 报警信息
```shell
INFO: task jbd2/sda-8:1343 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
jbd2/sda-8      D ffff9a57fd51acc0     0  1343      2 0x00000000
Call Trace:
[<ffffffff96ad2b90>] ? task_rq_unlock+0x20/0x20
[<ffffffff97188f49>] schedule+0x29/0x70
[<ffffffffc0e1a33c>] jbd2_journal_commit_transaction+0x23c/0x19c0 [jbd2]
[<ffffffff96ae12ae>] ? account_entity_dequeue+0xae/0xd0
[<ffffffff96ae4bcc>] ? dequeue_entity+0x11c/0x5c0
[<ffffffff96ae61d1>] ? put_prev_entity+0x31/0x400
[<ffffffff96a2b59e>] ? __switch_to+0xce/0x580
[<ffffffff96ac6e90>] ? wake_up_atomic_t+0x30/0x30
[<ffffffff97188a77>] ? __schedule+0x3c7/0x870
[<ffffffff96aae01e>] ? try_to_del_timer_sync+0x5e/0x90
[<ffffffffc0e20f89>] kjournald2+0xc9/0x260 [jbd2]
[<ffffffff96ac6e90>] ? wake_up_atomic_t+0x30/0x30
[<ffffffffc0e20ec0>] ? commit_timeout+0x10/0x10 [jbd2]
[<ffffffff96ac5da1>] kthread+0xd1/0xe0
[<ffffffff96ac5cd0>] ? insert_kthread_work+0x40/0x40
[<ffffffff97195ddd>] ret_from_fork_nospec_begin+0x7/0x21
[<ffffffff96ac5cd0>] ? insert_kthread_work+0x40/0x40
```

##### 止血方案：
由于是一个容器node节点，对节点上所有pod进行驱逐后，还有一个java进程CPU占用很高，并无法驱逐，进行手动 kill -9 删除

`kill -9 1234`

删除失败，由于该进程已经进入D状态（disk sleep | uninterruptible sleep），所以无法用普通的kill -9方法进行删除，只能通过reboot系统或者变更进程状态后再kill的方法进行，尽量不重启系统的情况下，选择对进程状态进行变更的方案：
```shell
mkdir /tmp/killed
cd /tmp/killed

vi killd.c
###
#include <linux/init.h>
#include <linux/kernel.h> /*Needed by all modules*/
#include <linux/module.h>
#include <linux/sched.h> //for_each_process
MODULE_LICENSE("BSD");
static int pid = -1;
module_param(pid, int, S_IRUGO);
static int killd_init(void)
{
    struct task_struct * p;
    printk(KERN_ALERT "killd: force D status process to death/n");
    printk(KERN_ALERT "killd: pid=%d/n", pid);
    //read_lock(&tasklist_lock);
    for_each_process(p){
        if(p->pid == pid){
            printk("killd: found/n");
            set_task_state(p, TASK_STOPPED);
            printk(KERN_ALERT "killd: aha, dead already/n");
            return 0;
        }
    }
    printk("not found");
    //read_unlock(&tasklist_lock);
    return 0;
}
static void killd_exit(void)
{
    printk(KERN_ALERT "killd: bye/n");
}
module_init(killd_init);
module_exit(killd_exit);
###

vi Makefile
###C文件空格需使用TAB键，不然编译时会报错
obj-m := killd.o
all :
        $(MAKE) -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules 
clean:
        $(MAKE) -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
###
make

insmod ./killd.c pid=1234
kill -15 1234
```
kill进程之后系统load负载立刻下降了，具体根因还未知，待深入排查。

##### 根因推测：
对于几个异常点可能的推断：
1. load负载飙高，cpu使用率不高，推测可能是基于磁盘、网络或者其他IO类阻塞造成队列阻塞，实际性能处理并不多
1. iowait升高，可能磁盘性能，坏块，或者死锁造成，具体未知
1. vmstat中b队列较高，结合第一点大概率是由于进程阻塞造成b队列增长
1. iostat中写操作归0，读操作升高；对于写操作归0可能由于阻塞造成，读操作升高原因未知
1. cache/buffer被释放清0，具体原因未知
1. sar -B 发现pgscand/s升高；推测可能因为内存cache/buffer被释放清0，pgscand对内存进行scan造成
1. message中发现jbd2锁告警，由于是message日志中最早出现的锁告警进程，怀疑是否有死锁情况，未知
1. 某java进程无法删除，进程进入D状态；进入D状态（uninterruptible sleep）的进程通常是在等待IO，这里推测可能是磁盘问题或者锁问题造成

综合上述的一些推测，怀疑
- 是否有进程（java或jdb2）持有锁未释放，出现死锁后IO阻塞积压导致load负载升高。
- RIAD卡，主板BIOS是否存在版本bug可尝试试点升级版本
- 硬盘是否存在未知坏块

具体还待验证。

- 更新进展：
通过对message日志的再次分析，发现故障时间点最先抛出锁异常的是jdb2进程，如下
```shell
jbd2_journal_commit_transaction+0x23c/0x19c0 [jbd2]
```

内核的 Journal 线程阻塞在jbd2_journal_commit_transaction函数，之后所有的进程都在等待锁释放：

![size:00,1000](/storage/2023/02-24/JecpnJvuX1PXgh516pl4cXjo6PS9rRPcHVNNIMop.png)

因此内核的Journal线程jbd2/sda-8阻塞是造成后续其他进程被阻塞的原因，此时整个ext4文件系统的文件操作都无法继续进行，并且在message当天的日志中发现有个POD出现了3次OOM的情况，结合网络上一篇文章的类似问题分享，做出一些推断（https://cloud.tencent.com/developer/article/1982759）

**总结内容大致是在k8s集群的node上的某个pod在写IO时进入 __getblk()等待可用的内存,只有拿到足够内存，才能完成ext4_journal_stop()将 t_updates 递减，其对应的内核 Journal 线程才能被唤醒，但是由于该pod的内存占用已经达到了其运行使用的上限，且无可回收的内存，导致进程触发了pod所在memory cgroup oom，但是由于引起oom的进程因为申请不到足够的内存无法从__getblk()函数里退出到handle_mm_fault去触发oom kill释放，最终引起了死循环。**

- 问题解决：

通过调整pod mem limit避免容器内存触发oom可以规避该问题，但是容器场景下oom是很难完全避免的，特别是在混布场景下而其中一个业务pod 频繁oom触发内核问题会导致整个node的业务pod都不可用，需要从内核代码逻辑里看下问题是如何触发的以及新版本是否有相应的优化。

分析cgroup分配内存的相关代码，如果gfp_mask带了__GFP_NOFAIL标记，那么即使cgroup已用内存超过cgroup memory limit也可以申请成功，只是会把超过的新申请内存page统计到root memory cgroup里去，但是为什么没有生效，最后在网上发现在2020-12有用户在centos官方反馈过 __GFP_NOFAIL标记丢失的情况，截止3.10.0-1160.36.2.el7.x86_64版本centos7还未有修复该问题。

- 补充
在某些情况下在系统中快速找到D进程，使用以下脚本
```shell
# 只有pid号及状态
ls /proc | grep '^[0-9]' | while read pid; do 
  if [ -f /proc/$pid/stat ]; then
    stat=$(awk '{print $3}' /proc/$pid/stat 2>/dev/null)
    cmd=$(cat /proc/$pid/cmdline 2>/dev/null | tr '\0' ' ')
    [[ $stat == "D" ]] && echo "PID $pid is in D state: $cmd"
  fi
done
#
# 带pid号及cmd命令
ls /proc | grep '^[0-9]' | while read pid; do 
  if [ -r /proc/$pid/stat ] && [ -r /proc/$pid/cmdline ]; then
    stat=$(awk '{print $3}' /proc/$pid/stat 2>/dev/null)
    cmd=$(tr '\0' ' ' < /proc/$pid/cmdline 2>/dev/null | sed 's/ $//')
    [[ $stat == "D" ]] && printf "PID %-6s in D state: %s\n" "$pid" "$cmd"
  fi
done
```

有些D进程在内核态中等待驱动或者硬件底层时可能在查找cmdline时卡住，这时需要用只查询pid号及状态的脚本进行查询，锁定卡主的PID号并通过以下命令定位进程，父进程，执行目录等信息：
```shell
# 查看进程状态和父进程
cat /proc/54189/stat 2>/dev/null | awk '{print "State:", $3, "Parent PID:", $4, "Executable:", $2}'

# 查看进程打开的文件（可能卡住，但可以尝试）
ls -l /proc/54189/fd/ 2>/dev/null

# 查看进程的 cgroup（如果是容器或服务）
cat /proc/54189/cgroup 2>/dev/null
```