尝试找出linux服务器性能瓶颈--影响平均负载的几类因素-阿里云开发者社区

开发者社区> 开发与运维> 正文

尝试找出linux服务器性能瓶颈--影响平均负载的几类因素

简介: linux系统的多任务处理能力受到广泛偏好,但性能瓶颈的指标非常繁多。我们今天来看一下如何查看系统性能负载的瓶颈。我们用性能测试的软件模拟下环境。来探究下如何发现真正的性能瓶颈

写在前面:
本篇文章融合了网络上多方的内容进行整合,经过实际操作成功后进行的重新编译。比如问题角度的变换引起的性能测试工具或参数的变动等。某些关键知识点也会有相应的补充。
实验实例采用阿里云ECS产品,参数为2C8G T5型实例,CentOS 7.4系统。除了安装软件的方式有所不同,Ubuntu、rh等其他版本的操作系统同样适用。
用到的工具有stress、stress-ng、sysstat
重要提示:其中sysstat需要更新到最新版本才能反馈iowait等参数变化

Linux 性能优化实践:
当服务器出现性能瓶颈,我们都习惯用top或uptime命令,来查看服务器当前的状态。比如uptime

$ uptime
08:26:48 up 3 days, 17:11, 2 users, load average: 0.00, 0.01,
0.05

展示的字段分别为
08:26:48 当前时间
up 3 days 系统从上次开机开始已经运行了多久
2 users 目前有几个终端连接服务器
后三个数 依次是过去1分钟、5分钟、15分钟的平均负载

平均负载是什么?我们可以执行man 命令,来了解详细解释。
image

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

可运行状态和不可中断状态又是什么?

可运行状态,是指正在使用CPU或者正在等待CPU的进程。
不可中断状态的进程则是处于内核态关键流程的进程,并且不可打断。比如常见的等待硬件设备的I/O响应,也就是我们在ps命令中看到的D状态进程。

举个例子:当一个进程向磁盘读写数据时,为了保证数据一致性,在磁盘回复前,他是不能被其他进程或者中断打断的,这个时候的进程就处于不可中断状态。如果此时的进程被打断了。就容易出现磁盘与进程数据不一致的问题。
所以,不可中断状态实际上是系统对进程和硬件设备的一种保护机制。

因此我们可以简单的认为,平均负载其实就是平均活跃进程数。既然是平均活跃进程数,那么最理想的就是每个CPU上都刚好运行着一个进程,这样每个CPU都得到了充分利用。比如负载是2的时候,就意味着CPU数小于2,就意味着一半的进程需要等待CPU的响应。这里的CPU数,我们在/proc/cpuinfo条目中就可以查看
image


有多少个不同的physical id 就有多少个CPU
siblings记录了对应的物理CPU有多少个逻辑核,逻辑核就是物理CPU用HT技术虚拟出来的逻辑处理单元比如1核2线程。

再为初学者同步一个进程和线程的概念。

一个核心只能同时执行一个线程。进程是操作系统进行资源(包括cpu、内存、磁盘IO等)分配的最小单位。线程是cpu调度和分配的基本单位。我们打开的聊天工具,浏览器都是一个进程。进程可能有多个子任务,比如聊天工具要接受消息,发送消息,这些子任务就是线程。资源分配给进程,线程共享进程资源。关于更进一步的线程消耗我们后续的贴子里讲。

那么有了CPU个数,我们就可以判断出,当平均负载大于CPU个数的时候,系统就出现了过载。不过平均负载有1分钟,5跟中和15分钟。我们要参考哪一个?实际上都要看。比如上午11点的望京站一点都不堵,我们不能判断望京站不堵。那具体我们要怎么看?

1.如果1分钟、5分钟、15分钟的三个值基本相同,或者相差不大,那就说明系统负载很平稳。
2.如果1分钟的值远小于15分钟说明最近1分钟负载在减小。相反则说明最近1分钟负载在增加。

如果在实际生产环境中,平均负载高于CPU数量70%的时候,我们就要关注了。

平均负载和CPU利用率

我们在实际工作中,很容易把平均负载和CPU使用率混淆。平均负载指的是平均进程数,它不仅包括了正在使用CPU的进程,还包括了等待CPU和等待I/O的进程。
而CPU使用率,是单位时间内CPU繁忙情况的统计,跟平均负载并不一定完全对应,比如:

CPU密集型进程,使用大量CPU会导致平均负载升高。此时两者是一致的。
I/O密集型进程,等待I/O也会导致平均敷在升高,但CPU使用率不一定高。
大量等待CPU的进程调度也会导致平均负载升高,此时的CPU使用率也会比较高。

如果需要看上述三种情况的具体细节,我们可以用iostat、mpstat、pidstat等工具,找出平均负载升高的根源。

下面根据上述的三种情况我们一起来测试一下:

测试前先记录一下一段时间的平均负载
image

场景一:开启一个终端运行stress命令,模拟一个CPU使用率100%的情况。

image
执行Uptime可以看到平均负载上升
image
执行mpstat可以看到一个CPU跑满
image
再开启一个终端运行pidstat来查看哪个进程导致这种情况
image
可以看到是stress进程导致的100%

场景二:开启一个终端运行I/O密集型进程模拟I/O压力, 即不停执行sync(缓存写盘):

(这里使用stress的升级版stress-ng,因为新的虚拟机可能缓存区比较小。做sync操作大部分消耗都在系统消耗内。)
开启终端运行uptime查看平均负载
image
再执行mpstat查看,这次的CPU平均负载升高是因为大量的IO请求待处理。
image
在第三个终端上可以用pidstat查看哪个进程导致了io升高
image
可以看到同样是stress造成的。

场景三:开启一个终端用stress模拟CPU繁忙的场景,由于我们实验实例是2核心的CPU,测试就用4个进程模拟做运算。

image
再用uptime查看下平均负载情况
image
再开启一个终端用mpstat查看CPU使用率的变化情况
image
可以看到平均负载慢慢增加到1.17。另一个终端可以看到CPU利用率为99.8%。iowait只有0.01,说明平均负载升高由于CPU过度繁忙。
我们再用pidstat命令查看那个进程导致CPU飙升,可以看到是我们进行性能测试的stress进程导致。
image

PS:过程中我们试图将stress的 —cpu参数调制100。系统运行基础指令都开始卡顿。

如此我们可以归纳下平均负载

平均负载提供了一个快速查看整体系统性能的手段,反映了整体的负载情况。但只看平均负载本身并不能直接看到问题出现在哪里。所以我们可以关注上述的三种可以使CPU平均负载上升的情况。可以用uptime先看分时段的CPU平均负载。用mpstat查看平均负载升高是由于什么原因。pidstat来查看究竟是哪个进程造成了平均负载的升高。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章