通过常用的top、iostat 、iotop 等命令查看，有一定的读写，cpu iowait 很高，实际压力不大。

top结果，iowait高，有一些st现象

iotop结果，读写很少。

ps auxf 查看进程，有几个怀疑对象，如 红框 id  103166  ，随后lsof -p 进程id，竟然卡住了，怀疑加深，同时df -h查询，卡住无响应，问号变多 

查找状态D不可中断的进程--客户的方法

查找状态D不可中断的进程--我的方法见这篇 http://rebootcat.com/2017/12/14/instability-of-cpu/查询结果， 代码存档如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

#!/usr/bin/env python
#-*- coding:utf-8 -*-

import os
import time

def run():
  result = []
  timestamp = time.strftime('%Y-%m-%d %H:%M:%S', time.localtime(time.time()))
  cmd = 'ps auxf'
  ret = os.popen(cmd).readlines()
  for i in ret:
    item = i.split()
    if len(item) > 7:
      item = item[7]
      if item == 'D':
        result.append(i)

  for r in result:
    process = '%s %s' % ( timestamp,r[:-1])
    print process

  if result:
    print '\n'

if __name__ == "__main__":
  while True:
    run()
    time.sleep(0.5)

同样指向 103166、12584、60477等进程

查看进程 103166来进行突破, 发现卡在管道这里

继续查stack，终于找到nfs_wait_killable 字样，与客户确认，他们做了日志持持久化，挂载了nfs服务，当时nfs 服务挂过一次，至此基本确认是nfs服务挂了引起的锅。

• 网上找到1篇文章，说的正好是nfs相关挂起 https://www.cnblogs.com/embedded-linux/p/7043569.html

D状态，往往是由于 I/O 资源得不到满足，而引发等待，在内核源码 fs/proc/array.c 里，其文字定义为“ "D (disk sleep)", /* 2 */ ”（由此可知 D 原是Disk的打头字母），对应着 include/linux/sched.h 里的“ #define TASK_UNINTERRUPTIBLE 2 ”。

举个例子，当 NFS 服务端关闭之时，若未事先 umount 相关目录，在 NFS 客户端执行 df 就会挂住整个登录会话，按 Ctrl+C 、Ctrl+Z 都无济于事。断开连接再登录，执行 ps axf 则看到刚才的 df 进程状态位已变成了 D ，kill -9 无法杀灭。

正确的处理方式，是马上恢复 NFS 服务端，再度提供服务，刚才挂起的 df 进程发现了其苦苦等待的资源，便完成任务，自动消亡。若 NFS 服务端无法恢复服务，在 reboot 之前也应将 /etc/mtab 里的相关 NFS mount 项删除，以免 reboot 过程例行调用 netfs stop 时再次发生等待资源，导致系统重启过程挂起。

• 客户也找到一篇介绍  https://segmentfault.com/a/1190000022829696

当pvc重新被挂载时，如果pod是被调度到不同的node，好像没问题。线上出问题的现象是nfs所在主机突然挂了，然后pod一直等待就hang住报错，然后我们手动去重启就会开始调度，调度到同一个的话，就算原pvc存在感觉认不到，要手动删除pvc后中间挂载，这个时候会出现僵尸进程。调度到不同的node不会出现任何问题。

• 参考前面2段提示，客户 先恢复了nfs 服务，然后在宿主机上 unmount 掉对应的 /etc/mtab 信息，卡死问题解决，僵尸进程消失，iowait 降下来了，问题解决。