GaussDB(DWS)-集群告警出现大量D/Z进程
D/Z告警排查
一、D/Z进程解释
D进程:
什么是D进程:
D 是 Disk Sleep 的缩写, 也就是不可中断状态睡眠(Uninterruptible Sleep) ,一般表示进程正在跟硬件交互,并且交互过程不允许被其他进程或中断打断。
为什么不能被中断:
不可中断,指的并不是CPU不响应外部硬件的中断,而是指进程不响应异步信号。绝大多数情况下,进程处在睡眠状态时,总是应该能够响应异步信号的。而内核的某些处理流程是不能被打断的。如果响应异步信号,程序的执行流程中就会被插入一段用于处理异步信号的流程(这个插入的流程可能只存在于内核态,也可能延伸到用户态),于是原有的流程就被中断了。
D进程的成因:
D状态进程通常是由于IO末能及时得到满足,如果进程正在等待的IO没有及时完成或响应,那么就会在ps等输出中看到,而一旦IO完成,该进程就可以继续运行,D 状态自行消失。如果D状态一直无法得到IO满足,可能是外设本身出了故障,也可能是比如挂载的远程文件系统已经不可访问(由down掉的NFS服务器引起的D状态),kill -9 等命令都无法将其杀掉。这种情况下,除了等待IO恢复,或是重启系统,在系统层面并没有办法删除这些进程。
D进程的危害:
D进程持续存在PID一直未变化,可能引发服务器load负载高,CPU占用低的现象,导致服务器hang或者持续卡顿。
Z进程:
什么是Z进程
Z 是 Zombie 的缩写, 它表示僵尸进程, 也就是进程实际上已经结束了,但是父进程还没有回收它的资源(比如进程的描述符.PID 等)。
Z进程的成因:
子进程先于父进程退出,子进程的用户空间被系统释放。但是这时,父进程没有读到子进程的返回代码,不知道子进程退出了。因为父进程没有读到子进程的返回代码,所以系统故意残留了子进程内核空间里的部分PCB,导致子进程没有被回收完全,从而产生了僵尸态进程。
为什么系统会残留部分PCB:
这个子进程是父进程创建的,这个子进程咋死的父进程总得知道啊。正巧的是,子进程的退出原因就放在其PCB里面,所以当父进程没有读到子进程的返回代码时,系统就会留下该子进程的部分PCB,以供其父进程来读取子进程的退出原因并回收该PCB,回收完成后,子进程也会退出僵尸态
什么是PCB:
PCB(process control block),进程控制块,是我们学习操作系统后遇到的第一个数据结构描述,它是对系统的进程进行管理的重要依据,和进程管理相关的操作无一不用到PCB中的内容。一般情况下,PCB中包含以下内容:
(1)进程标识符(内部,外部)
(2)处理机的信息(通用寄存器,指令计数器,PSW,用户的栈指针)。
(3)进程调度信息(进程状态,进程的优先级,进程调度所需的其它信息,事件)
(4)进程控制信息(程序的数据的地址,资源清单,进程同步和通信机制,链接指针)
Z进程的危害:
由于僵尸进程并不做任何事情, 不会使用任何资源也不会影响其它进程, 因此存在僵尸进程也没什么坏处。不过由于进程表中的退出状态以及其它一些进程信息也是存储在内存中的,因此存在太多僵尸进程有时也会是一些问题。
二、排查是否存在D/Z进程
1.获取告警实例信息
登录FIM界面->运维->告警->对象, 获取告警实例信息
2.登录告警节点, 获取D/Z进程号和类型信息
ps -elf | grep -v "\[thread_checkio\]" | awk 'NR!= 1 {print $2, $3, $4}' | grep omm | awk -F' ' '{print $1, $3}' | grep -E "Z|D"
三、定位手段
3.1 D/Z进程偶现并自行消失:
如果D/Z进程存在,过一会就消失,或者查到的D/Z进程经常更换pid,这种现象正常
D进程
D状态进程通常是由于IO末能及时得到满足,如果进程正在等待的IO没有及时完成或响应,那么就会在ps等输出中看到,而一旦IO完成,该进程就可以继续运行,D 状态自行消失。使用DWS时,批量的往数据库导入数据,如果导入的数据量大到OS脏页回写的速度赶不上写入的速度时,并且用户刷脏页的阈值到达,用户进程会需要主动刷脏页。OS脏页超过20%时,用户调write也需要主动的刷脏页,就会看到进程处于D状态,直到脏页水位下降到10%以下。
另:操作系统脏数据相关参数调整命令(用于解决脏数据引起的操作系统内核卡顿,导致dn主备切换):
相关参数:
#dirty_background_ratio控制脏页占可用内存(空闲+可回收)的百分比,达到dirty_background_ratio时,内核的flush线程开始回写脏页。默认值: 10
vm.dirty_background_ratio = 10
#dirty_background_bytes控制脏页内存数量,超过dirty_background_bytes时,内核的flush线程开始回写脏页
vm.dirty_background_bytes = 0
vm.dirty_ratio = 20
#控制脏页所占可用内存百分比,达到dirty_ratio时,执行磁盘写操作的进程自己开始回写脏数据。默认值:20
#控制脏页内存数量,达到dirty_bytes时,执行磁盘写操作的进程开始回写脏页
vm.dirty_bytes = 0
#控制周期回写进程的唤醒时间,默认值为500,单位是厘秒,实际内核中是*10使用,即5s,也就是每隔5秒唤醒脏页回写进程,降低这个值可以把尖峰的写操作削平成多次写操作
vm.dirty_writeback_centisecs = 50
#控制dirty inode实际回写的等待时间,默认值是3000,即30s,只有当超过这个值后,内核回写进程才会将dirty数据回写到磁盘
vm.dirty_expire_centisecs = 6000
推荐修改操作:
#减少脏数据缓存相关参数
sysctl -w vm.dirty_ratio = 10
sysctl -w vm.dirty_background_ratio = 5
sysctl -p
Z进程
状态表示进程正在终止或已经被终止,这时的进程可能正在进行一些清理工作或已经被完全终止。如果进程正在进行清理工作,其gstack、maps和stack信息可能仍然存在并可以被查看。但是,如果进程已经被完全终止,那么这些信息可能已经消失或无法获取。
3.2 D/Z进程不消失:
D进程应急处理:
如果确认是D影响业务,需要重启服务器释放D进程
排查是否是D进程影响的手段:
1)使用 pidstat 查看这些进程的磁盘读写情况,如下:
# -d 展示 I/O 统计数据,-p 指定进程号,间隔 1 秒输出 3 组数据
pidstat -d -p XXX 1 3
iostat -xm 1 3
可以看到,这四个进程目前存在大量磁盘读写。
2)查看其余资源情况
top -p xxx
如果看到load在不断增加,而进程占用CPU不高,但是IO压力很大,可以判定为该D进程导致,持续不能满足IO且大范围影响业务,建议立即重启服务器。
Z进程应急处理:
既然僵尸进程是因为父进程没有回收子进程的资源而出现的,那么,要解决掉它们,就要找到它们的根儿,也就是找出父进程,然后在父进程里解决。
# -a 表示输出命令行选项 -p 表PID -s 表示指定进程的父进程
pstree -aps XXX
kill -9 父进程即可
D进程根因定位:
方法一:
# 记录性能事件,等待大约15秒后按 Ctrl+C 退出
$ perf record -g
# 查看报告
$ perf report
检查对应进程堆栈信息
方法二:
从RHEL5.5 版开始,RHEL包含一个内核线程,用于监视停留在D状态超过指定超时时间的进程。默认情况下,超时时间为120秒,可以使用内核参数 kernel.hung_task_timeout_secs修改或禁用它。当检测到此类进程时,该内核线程将有关该进程的信息(包括其内核堆栈跟踪)转储
#超时时间,默认值120
echo '120' > /proc/sys/kernel/hung_task_timeout_secs
#是否在检测到hung后panic,默认值0 --可选,不推荐修改
echo '0' > /proc/sys/kernel/hung_task_panic
进入 /var/log/messages查看堆栈
方法三:
使用sysrq工具将有关进程的信息发送到/var/log/messages
# 启用sysrq的功能:
echo 1 > /proc/sys/kernel/sysrq
# 转储处于不可中断(阻塞)状态的任务。
echo w > /proc/sysrq-trigger
# 将当前任务列表及其信息转储到您的控制台。
echo t > /proc/sysrq-trigger
# 显示所有活动 CPU 的堆栈回溯。
echo l > /proc/sysrq-trigger
这会将任务和线程信息转储到/var/log/messages
Z进程根因定位:
cat /proc/${pid}/stack
四、相关案例
五、参考文档
麒麟V10,操作系统脏数据相关参数调整命令(用于解决脏数据引起的操作系统内核卡顿,导致dn主备切换)
案例:系统中出现大量不可中断进程(D)和僵尸进程(Z)怎么办?
Linux磁盘I/O(二):使用vm.dirty_ratio和vm.dirty_background_ratio优化磁盘性能
- 点赞
- 收藏
- 关注作者
评论(0)