锁定该进程(忽略SIGKILL)是可运行的(不是僵尸或处于不间断的睡眠状态)。它处于什么状态?


17

我有一个进程,现在已经有几次停止响应了,并且似乎已完全锁定。它不会响应任何使用gdb进行strace或偷看的尝试(gdb挂在wait4()syscall上)。该进程是可运行的,并且不等待syscall(/ proc / X / syscall:)running或处于不间断的睡眠状态(/ proc / X / status:)State: R (running)

这个过程到底处于什么状态?这可能是某种类型的内核错误吗?

该过程是redis,现在已经发生了几次。看来,唯一可以杀死该进程的是重新启动。操作系统为美分7。

编辑:内核版本是3.10.0-123.13.2.el7.x86_64。尝试更新到3.10.0-229.11.1.el7,以查看是否有任何区别。


它使用什么版本的GDB?根据stackoverflow.com/questions/8978777/…,较新的版本可能会更好。
格雷格·布雷

目前,由于挂起的特殊方式,调查似乎更多地是在内核方面,但是如果您不介意,可以添加一些Redis特定信息吗?进程阻塞时正在做什么,诸如此类。我通过Twitter从Nick Craver获得了一些信息,显然,Redis在发生这种情况时正在加载大型数据集,是重新启动进程还是以其他方式(例如,通过DEBUG RELOAD或流水处理大量数据)加载了数据集。 )?谢谢。

@antirez该数据集由另一个redis实例的rdb副本加载。锁定发生在redis启动并读取巨型rdb之后。值得注意的是,它有时并不总是锁定。
2015年

1
发生IO错误时,我只会遇到此类问题。您能告诉我们有关dmesg输出的信息吗?
1

3
什么是/proc/<pid>/stack(和/proc/<pid>/task/*/stack)包含哪些内容?这个过程有几个线程吗?
斯特凡Chazelas

Answers:


2

wait4是一个系统调用,指示进程正在等待其子终止之一。这可能会指出信号处理方面的一些问题。

有点残酷,但是您可以尝试终止应用程序的层次结构kill -15 -$YourRedisPID。本-前PID手段“的PID和它的孩子。” 由于似乎正在等待孩子的解雇,因此它可能会解锁。

如果它不起作用,让我们更深入地检查:使用以下命令查找信号处理状态 grep ^Sig /proc/$YourRedisPID/status

您会看到一些类似的内容:

SigQ:   8/62777
SigPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000080
SigCgt: 0000000180004023

如内核源代码“ fs / proc / array.c”中所定义,“ SigQ”是待处理信号的数量/待处理信号的限制。

如果信号数量过多,则可能表明您的“ SIGKILL”根本没有被处理。我仍在检查“ kernel / signal.c”文件以了解这些特殊信号的信号管理。

为了直接了解输出,请尝试以下一种代码: awk 'BEGIN{print "ibase=16;obase=2;"} /^Sig...:/{ print toupper($2)}' /proc/$YourRedisPID/status | BC_LINE_LENGTH=0 bc

这输出我:

0
0
10000000
110000000000000000100000000100011

让我们开始发送此输出。我将根据需要更新帖子。


该进程不在wait4()中,尝试访问该进程时gdb挂在wait4()上。该进程本身不在任何系统调用中。而且,挂起进程没有孩子。不幸的是我不得不重启盒子。问题再次发生后,我会收集您要求的数据。
2015年

输出在这里:gist.githubusercontent.com/alienth/23685ad2ea46a7eade56/raw/… 再次,proc忽略了SIGKILL。它不在系统调用中。Proc还忽略了SIGTERM。
2015年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.