生产故障之nfs挂载导致系统负载巨高

起因
最近我们在执行代码更新的时候执行saltstack接收反馈信息特别慢，有时候还会出现卡住的现象，而我们的执行流程是通过saltstack-master 发送指令给阿里云部署的enter机，由enter机去执行salt指令，

那么我们就登录到这台阿里云的enter机上，执行top发现机器负载很高，但是CPU、内存、磁盘IO、网络IO使用率都不高

负载的状态

1、uninterruptible （等待磁盘输入输出/不可中断状态）
2、nterruptible （等待键盘输入输出/可中断状态）
3、running（正在运行）

什么是负载？
负载表示的是等待进程的平均数。在上面进程状态变换过程中，除了running状态，其他都是等待状态，那么其他状态都会加入到负载等待进程中吗？

事实证明，只有进程处于运行态（running）和不可中断状态（interruptible）才会被加入到负载等待进程中，也就是下面这两种情况的进程才会表现为负载的值

• 即便需要立即使用CPU，也还需等待其他进程用完CPU
• 即便需要继续处理，也必须等待磁盘输入输出完成才能进行

什么场景会造成CPU低而负载确很高呢？
通过上面的具体分析负载的意义就很明显了，负载总结为一句话就是：需要运行处理但又必须等待队列前的进程处理完成的进程个数。具体来说，也就是如下两种情况：

• 等待被授权予CPU运行权限的进程
• 等待磁盘I/O完成的进程

cpu低而负载高也就是说等待磁盘I/O完成的进程过多，就会导致队列长度过大，这样就体现到负载过大了，但实际是此时cpu被分配去执行别的任务或空闲，具体场景有如下几种。

场景一：磁盘读写请求过多就会导致大量I/O等待
场景二：MySQL中存在没有索引的语句或存在死锁等情况
场景三：外接硬盘故障，常见有挂了NFS，但是NFS server故障

1、解决当前问题的思路
我们了解了系统负载的基本知识后，开始分析
1、系统负载其实就是运行态或者是不可中断状态下的进程反馈的状态
2、当时考虑了负载高的问题可能出现的场景，那么最有可能出问题的其实就是场景三,nfs导致负载高
3、那么首先该阿里云的enter机确实是有做nfs的挂载，是将华为云的一台elk的机器，挂载到本地的/mnt目录，而该机器正好前段时间被我们初始化了
4、出现该问题的原因主要是，在根目录下ls的时候直接卡住，因为nfs服务端已经挂掉了，那么就会导致进程读写请求一直获取不到资源，从而进程一直是不可中断状态，并且该ls 进程还特别多，导致cpu的上下文切换，造成负载很高。

2、开始处理故障

1.先把nfs挂载给卸载

umount /mnt

2.重启服务器
这个ls进程因为是不可中断状态，那么只能重启机器

reboot  
或
在云的控制台执行重启操作

3.重启完成后即可完成恢复

uptime