选择语言
< 返回主菜单
常见问题
linux系统运行中爆发D进程
宣布时间： 2019年12月17日
问题描述
https://access.redhat.com/solutions/31453
https://access.redhat.com/zh_CN/solutions/695633
系统变为无响应状态并爆发以下信息 "INFO: task <process>:<pid> 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 <process>:<pid> 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 <process>:<pid> 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: [<ffffffff80063ff8>] thread_return+0x62/0xfe [<ffffffff88036d8a>] :jbd:log_wait_commit+0xa3/0xf5 [<ffffffff800a1ba4>] autoremove_wake_function+0x0/0x2e [<ffffffff8803178a>] :jbd:journal_stop+0x1cf/0x1ff [<ffffffff8002ff40>] __writeback_single_inode+0x1e9/0x328 [<ffffffff800e1464>] do_readv_writev+0x26e/0x291 [<ffffffff800f3d9d>] sync_inode+0x24/0x33 [<ffffffff8804c36d>] :ext3:ext3_sync_file+0xc9/0xdc [<ffffffff8005073a>] do_fsync+0x52/0xa4 [<ffffffff800e1ce9>] __do_fsync+0x23/0x36 [<ffffffff8005e28d>] 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*- 检查这个问题是否是因为使用远程文件系统（如 NFS）造成处理延迟。例如，如果有大宗 NFS 效劳器请求，就可能会造成这个问题。
Raw
$ grep MYAPP lsof | grep oracleMYAPP 7096 1062 cwd DIR 0,18 0 558301 /oracle/prd/fs_ne/inst/conc/log...$ grep nfs mountremotehost@:/ on /oracle/prd/fs_ne/inst type nfs (rw,nosuid)
