linux系统运行中爆发D历程

宣布时间： 2019年12月17日

https://access.redhat.com/solutions/31453

https://access.redhat.com/zh_CN/solutions/695633

:blockedformorethan120seconds"." style="margin: 30px 0px 0px; padding: 0px; color: rgb(51, 51, 51); font-size: 24px; font-weight: normal; line-height: 1.25; border-bottom-color: rgb(204, 204, 204); font-family: Arial, sans-serif;">系统变为无响应状态并爆发以下信息 "INFO: task : blocked for more than 120 seconds".

Solution 已验证?- 已更新 2018年三月20日07:56 -?
中文 (中国)

?? Red Hat Enterprise Linux (RHEL) 5.5 (kernel-2.6.18-194) 或更高版本

?? Red Hat Enterprise Linux (RHEL) 6

?? Red Hat Enterprise Linux (RHEL) 7

?? 历程处于无法中止的睡眠状态 (D state)

?? 在系统变为无响应前，/var/log/messages 中纪录了以下信息：

Raw

INFO: task : blocked for more than 120 seconds

?? 是什么缘故原由导致爆发上面的信息？在对这个问题举行故障扫除时需要什么信息？

这些信息通常意味着，系统保存磁盘或内存壅闭问题，历程无法获得可用的资源。
请参阅 "How do I use hung task check?" 中 CAUTIONS 一段的内容。
这些信息通常用来提醒用户注重与操作优化有关的问题。这些信息并纷歧定代表泛起了严重的问题，而被壅闭的历程通�；嵩谙低郴指凑Ｗ刺北淮χ贸头�。
若是需要进一步的故障诊断，凭证?How do I use hung task check in RHEL ??的内容爆发一个 vmcore，并和红帽的手艺支持一起合作剖析 vmcore。
若是处于挂起状态的使命是第三方的应用程序，请同时请求相关应用程序厂商的支持。
若是您已相识到这些使命挂起信息是由于特定过失造成的，您也可以榨取爆发这些信息。可是，我们并不建议这样做，这也不可能避免使命挂起问题的泛起。若是您需要榨取爆发这些信息，请举行以下操作：

# sysctl kernel.hung_task_timeout_secs=0

若是使命挂起导致系统瓦解，并且您已知道了造成这个问题的缘故原由，则可以通过把以下内容添加到 /etc/sysctl.conf 中来阻止系统瓦解。在举行改变后，需要运行 'sysctl -p' 以使改变生效。

Raw

kernel.hung_task_panic = 0

Red Hat Enterprise Linux 5.5 使用的内核版本?2.6.18-194?中增添了一个 Detect Hung Task 内核线程 (khungtaskd)，它的功效是检测到那些已处于 D-state ( Uninterruptible Sleep (UN) ) 状态凌驾了一准时间（默认是 120 秒）的使命，并把以下类型的信息纪录到系统日志文件中（例如，/var/log/messages）。

Raw

"INFO: task : blocked for more than 120 seconds"

khungtaskd?内核线程会监控历程的状态，并检查是否有历程已处于不可中止的状态凌驾了 "kernel.hung_task_timeout_secs" sysctl 参数所设定的时间长度（这个系统参数的默认值是 120 秒）。若是保存这样的历程，它会在日志中纪录这个情形，并纪录下壅闭历程的挪用回溯信息。为了避免爆发大宗的日志数据，在默认情形下，这个监控历程只会报告检测到的最先爆发的 10 个挂起使命，以后将不再报告。因此，纵然不再爆发相关的信息，仍然有可能保存壅闭的使命。
检查与以下类似的信息：

Raw

INFO: task syslogd:2643 blocked for more than 120 seconds.?

"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.?

syslogd D ffff81000237eaa0 0 2643 1 2646 2634?

(NOTLB)??

ffff8101352c3d88 0000000000000086 ffff8101352c3d98 ffffffff80063ff8?

0000000000001000 0000000000000009 ffff81013d2c57e0 ffff810102ac1820?

0000340b30708992 0000000000000571 ffff81013d2c59c8 000000010000089f?

Call Trace:?

[] thread_return+0x62/0xfe?

[] :jbd:log_wait_commit+0xa3/0xf5?

[] autoremove_wake_function+0x0/0x2e?

[] :jbd:journal_stop+0x1cf/0x1ff?

[] __writeback_single_inode+0x1e9/0x328?

[] do_readv_writev+0x26e/0x291?

[] sync_inode+0x24/0x33?

[] :ext3:ext3_sync_file+0xc9/0xdc?

[] do_fsync+0x52/0xa4?

[] __do_fsync+0x23/0x36?

[] tracesys+0xd5/0xe0

Raw

# uname -a > /tmp/uname.out

# ifconfig > /tmp/ifcongfig.out

# top -n 5 -b > /tmp/top.out

# vmstat 1 50 > /tmp/vm.out

# iostat -x 2 10 > /tmp/io.out

# ps aux > /tmp/ps.out

# ps auxH > /tmp/psh.out

# sar -A > /tmp/sar.out

# free > /tmp/free.out

# lsof > /tmp/lsof.out

运行以下下令以提供相关的数据：
Raw

# tar -cjvf outputs.tar.bz2 /tmp/*.out

# tar -cjvf message.tar.bz2 /var/log/message*

Raw

$ grep MYAPP lsof | grep oracle

MYAPP??? 7096???? 1062? cwd??? DIR??? 0,18???? 0???? 558301 /oracle/prd/fs_ne/inst/conc/log

...

$ grep nfs mount

remotehost@:/ on /oracle/prd/fs_ne/inst type nfs (rw,nosuid)