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

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

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

负载的状态

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的上下文切换,造成负载很高。

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

2、开始处理故障

1.先把nfs挂载给卸载

umount /mnt

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

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

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

uptime