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

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


image.png

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


image.png

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


image.png

iotop发现mysqld占用大量的io


image.png

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

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

load负载和cpu之间关系:
参考: https://www.cnblogs.com/zhangyjblogs/p/14163576.html

## load average定义[#](https://www.cnblogs.com/zhangyjblogs/p/14163576.html#load-average%E5%AE%9A%E4%B9%89)

平均负载是指单位时间内,系统处于**可运行状态**和**不可中断状态**的平均进程数,也就是**平均活跃进程数**,它和CPU使用率并没有直接关系。

**可运行状态**的进程,是指**正在使用CPU或者正在等待CPU的进程**,也就是我们常用ps命令看到的,处于R状态(Running 或 Runnable)的进程。

**不可中断状态**的进程则是正处于内核态关键流程中的进程,并且这些流程是不可打断的,比如最常见的是等待硬件设备的I/O响应。

比如,当一个进程向磁盘读写数据时,为了保证数据的一致性,在得到磁盘回复前,它是不能被其他进程或者中断打断的,这个时候的进程就处于不可中断状态。如果此时的进程被打断了,就容易出现磁盘数据与进程数据不一致的问题。

因此前面自己的理解是错误的,比如1min内的平均负载load average指的是1min内**正在使用CPU进程+正在等待CPU的进程+等待IO的进程**,同理5min、15min也是如此计算。

但是,我们平时是java应用,一个应用开启多个线程,这个就涉及到线程和进程的关系了。

linux内进程就是我们ps -fe 看到的,线程是属于进程的,一个进程至少有一个线程,对于我们java应用来说,一个java进程通常有多个线程。线程又称为Light—Weight Process,cpu处理线程是使用分片法,线程也涉及到使用cpu资源和IO(线程向磁盘读写数据),因此平均负载也简单定义为1min内**正在使用CPU线程+正在等待CPU的线程+等待IO的线程**。

你可能感兴趣的:(解决linux cpu占用不高但是负载很高)