解决linux cpu占用不高但是负载很高

客户现场遇到mongodb cpu偶发性占用过高问题，配置16c16g，装了mysql,mongo,influxdb，java等应用，观察到mongodb在更新数据的时候很慢，几秒甚至几十秒。

通过vmstat 1 10发现bi很高达到2w，

top展开cpu发现有几个cpu的%wa经常在100%，初步判断硬盘负载很高，

用iostat -x 1 10果然硬盘%util达到100%了

iotop发现mysqld占用大量的io

看mysql的日志，发现有超时查询，加完索引后，系统正常。

回头看mongodb的查询慢、偶发性占用cpu 1600%只是表象，因为mongodb需要往硬盘写数据，这个时候硬盘被mysql占用，导致mongodb线程只能等io，mongodb写硬盘的请求积累，cpu也没释放，故cpu占用率高。

load负载和cpu之间关系：

参考： https://www.cnblogs.com/zhangyjblogs/p/14163576.html

有史以来负载突然居高的，有点吓人。

如图示：

PS: vmstat(Virtual Memory Statistics 虚拟内存统计) 命令用来显示Linux系统虚拟内存状态，也可以报告关于进程、内存、I/O等系统整体运行状态

发现奇葩的的--r值：这个高！！！

PS：

r: 运行队列中进程数量，这个值也可以判断是否需要增加CPU。（长期大于1）

正常的情况下的r值是：

可能有异常的情况很多的进程一直在创建

因为公司的业务又使用的一些定时的任务，定时执行一些服务。所有核查一下一些进程信息：

果然是这一推的进程在作祟！！！！！

直接结束上述的相关进程后，就好了！！

批量删除对应的进程：

批量删除示例：

说明：

“grep xxxx”的输出结果是，所有含有关键字“remind_service”的进程。

“grep -v xxxxx”是在列出的进程中去除含有关键字“color”的进程。

“cut -c 9-15”是截取输入行的第9个字符到第15个字符，而这正好是进程号PID。

“xargs kill -s 9”中的xargs命令是用来把前面命令的输出结果（PID）作为“kill -s 9”命令的参数，并执行该命令。“kill -s 9”会强行杀掉指定进程。

排查了下，不知道为啥定时执行的任务不断执行创建了！这个目前暂时还不是很清楚！

1、查看Linux系统CPU个数

2、每次发现系统变慢时，我们通常做的第一件事，就是执行top或者uptime命令

2.1、如果1分钟、5分钟、15分钟的三个值基本相同，或者相差不大，那就说明系统负载很平稳。​

2.2、但如果1分钟的值远小于15 分钟的值，就说明系统最近1分钟的负载在减少，而过去15分钟内却有很大的负载。

2.3、反过来，如果1分钟的值远大于 15 分钟的值，就说明最近1分钟的负载在增加，这种增加有可能只是临时性的，也有可能还会持续增加下去，所以就需要持续观察。一旦1分钟的平均负载接近或超过了CPU的个数，就意味着系统正在发生过载的问题，这时就得分析调查是哪里导致的问题，并要想办法优化了。

​​eg：假设我们在一个单 CPU 系统上看到平均负载为 1.73，0.60，7.98，那么说明在过去 1 分钟内，系统有 73% 的超载，而在 15 分钟内，有 698% 的超载，从整体趋势来看，系统的负载在降低。​ ​

2.4、当平均负载高于 CPU 数量70%的时候，你就应该分析排查负载高的问题了。一旦负载过高，就可能导致进程响应变慢，进而影响服务的正常功能。​

2.5、CPU 使用率，是单位时间内 CPU 繁忙情况的统计，跟平均负载并不一定完全对应

2.5.1、CPU 密集型进程，使用大量 CPU 会导致平均负载升高，此时这两者是一致的；

2.5.2、I/O 密集型进程，等待 I/O 也会导致平均负载升高，但 CPU 使用率不一定很高；

2.5.3、大量等待 CPU 的进程调度也会导致平均负载升高，此时的CPU使用率也会比较高。

3、使用工具iostat（stress）、mpstat、pidstat 等工具，找出平均负载升高的根源

3.1、stress 是一个 Linux 系统压力测试工具，这里我们用作异常进程模拟平均负载升高的场景​​

3.2、而 sysstat 包含了常用的 Linux 性能工具，用来监控和分析系统的性能。我们的案例会用到这个包的两个命令 mpstat 和 pidstat。​

3.2.1、mpstat 是一个常用的多核 CPU 性能分析工具，用来实时查看每个 CPU 的性能指标，以及所有CPU的平均指标。

3.2.2、pidstat 是一个常用的进程性能分析工具，用来实时查看进程的 CPU、内存、I/O 以及上下文切换等性能指标

首先，在第一个终端运行 stress 命令，模拟一个 CPU 使用率 100% 的场景

接着，在第二个终端运行uptime查看平均负载的变化情况

最后，在第三个终端运行mpstat查看 CPU 使用率的变化情况

那么到底是哪个进程，导致 iowait 这么高呢？我们还是用 pidstat 来查询

首先还是运行 stress 命令，但这次模拟 I/O 压力，即不停地执行 sync

还是在第二个终端运行uptime查看平均负载的变化情况

然后，第三个终端运行mpstat查看 CPU 使用率的变化情况

那么到底是哪个进程，导致 iowait 这么高呢？我们还是用 pidstat 来查询

当系统中运行进程超出 CPU 运行能力时，就会出现等待 CPU 的进程。比如，我们还是使用 stress，但这次模拟的是 4 个进程

由于系统只有 1 个CPU，明显比 4 个进程要少得多，因而，系统的 CPU 处于严重过载状态，平均负载高达3.71

接着再运行pidstat来看一下进程的情况

---