首页
视频
资源
登录
原
精
Linux 性能调优(平衡负载整合)
3118
人阅读
2020/7/19 0:46
总访问:
2534872
评论:
0
收藏:
0
手机
分类:
linux
![ubuntu](https://img.tnblog.net/arcimg/hb/d4362a6a18e949a29eea9dcdf50612ed.jpg "ubuntu") >#Linux 性能调优(平衡负载整合) [TOC] uptime命令的意义 ------------ >通常我们通过 `uptime` 来了解系统负载。 ![](https://img.tnblog.net/arcimg/hb/59f53d33eea54d5ead0817777659a90a.png) | 名称 | 含义 | | ------------ | ------------ | | 00:09:46 | 当前时间 | | up 12 days, 12:47 | 系统运行时间 | | 3 users | 用户数量 | | load average: 0.00, 0.02, 0.00 | 过去 1 分钟、5 分钟、15 分钟的平均负载(Load Average)。 | 你知道什么是“平均负载”? ------------ <br/> ###平均负载 tn>单位时间内,系统中处于 **可运行状态** 和 **不可中断状态** 的平均进程数。而不是单位时间内的cpu使用率。 <br/> ###可运行状态的进程 tn>正在使用cpu或者正在等待cpu的进程,即`ps aux`命令下STAT处于R状态的进程 <br/> ###不可中断状态的进程 tn>处于内核态关键流程中的进程,且不可被打断,如等待硬件设备IO响应,`ps`命令D状态的进程 <br/> ###理想状态 tn>每个cpu上都有一个活跃进程,即平均负载数等于cpu数 ###平衡负载与CPU区别 tn>CPU 使用率,是单位时间内 CPU 繁忙情况的统计,跟平均负载并不一定完全对应。例如常见的以下三点: **CPU 密集型进程,使用大量 CPU 会导致平均负载升高,此时这两者是一致的;** **I/O 密集型进程,等待 I/O 也会导致平均负载升高,但 CPU 使用率不一定很高;** **大量等待 CPU 的进程调度也会导致平均负载升高,此时的 CPU 使用率也会比较高。** <br/> tn>有网友解释:CPU比喻成一辆地铁,正在使用CPU的进程就是在地铁上的人;等待CPU的进程就是在下一站等地铁来的人;等待I/O的进程就是在下一站要上车和下车的人,虽然现在对CPU没影响,可未来会影响,所以也要考虑到平均负载上。(地铁的乘客容量就是CPU个数) <br/> 平均负载的案例分析 ------------ tn>运用 iostat、mpstat、pidstat 等工具,找出平均负载升高的根源。 实验准备 ------------ >- 准备一台Ubuntu 最好的配置2 CPU,8GB 内存。我的配置(cpu:1) ![](https://img.tnblog.net/arcimg/hb/2a0ffd7c427f42c8b35914371fa1cd43.png) >- 预先安装 stress 和 sysstat 包,如 `apt install stress sysstat`。 >- 准备三个终端 <br/> tn>实验工具介绍 stress 是一个 Linux 系统压力测试工具,这里我们用作异常进程模拟平均负载升高的场景。 mpstat 是一个常用的多核 CPU 性能分析工具,用来实时查看每个 CPU 的性能指标,以及所有 CPU 的平均指标。 pidstat 是一个常用的进程性能分析工具,用来实时查看进程的 CPU、内存、I/O 以及上下文切换等性能指标。 <br/> tn>额外工具介绍 网友推荐:htop看负载,因为它更直接(在F2配置中勾选所有开关项,打开颜色区分功能),不同的负载会用不同的颜色标识。比如cpu密集型的应用,它的负载颜色是绿色偏高,iowait的操作,它的负载颜色是红色偏高等等,根据这些指标再用`htop`的sort就很容易定位到有问题的进程。还有个更好用的`atop`命令,好像是基于sar的统计生成的报告,直接就把有问题的进程标红了,更直观。 我使用了一下,并截了一些图。分别是`htop`与`atop` <br/> ![](https://img.tnblog.net/arcimg/hb/2e452db33fcb438d837f34882b1c0079.png) <br/> ![](https://img.tnblog.net/arcimg/hb/a4a5a00afe974f2fb1e39215ce7b36f4.png) 相关命令 ------------ 1. `grep 'model name' /proc/cpuinfo | wc -l`查看CPU核数 2. `watch -d uptime: -d`会高亮显示变化的区域 3. `strees`: 压测命令,`--cpu` cpu压测选项,`-i` io压测选项,`-c` 进程数压测选项,`--timeout` 执行时间 4. `mpstat`: 多核cpu性能分析工具,`-P ALL`监视所有cpu 5. `pidstat`: 进程性能分析工具,`-u` 显示cpu利用率 实践显示出平均负载与cpu使用率的区别 ------------ ###情况1:CPU 密集型进程 <br/> >通过stress命令,模拟一个CPU使用率 100% 的场景 ```bash stress --cpu 1 --timeout 600 ``` ![](https://img.tnblog.net/arcimg/hb/c027e03cb176448fb4b7b96ad9a7226f.png) >然后,在第二个终端运行 uptime 查看平均负载的变化情况: ```bash uptime ``` ![](https://img.tnblog.net/arcimg/hb/482ad2c3e73e4304b682fd8d6934f9c5.png) >最后,在第三个终端运行 mpstat 查看 CPU 使用率的变化情况: ```bash mpstat -P ALL 5 ``` ![](https://img.tnblog.net/arcimg/hb/3dbb2deb003d4fc289d0d03960867237.png) >这里我们看到平均负载慢慢升高到1.00,而从终端三中还可以看到,正好有一个 CPU 的使用率接近为 100%(99.40%),但它的 iowait 只有 0。这说明,平均负载的升高正是由于 CPU 使用率为 100%所造成的 。 <br/> >最后通过 pidstat 工具定位是哪个进程使用CPU这么高 ```bash # 间隔5秒后输出一组数据 pidstat -u 5 1 ``` ![](https://img.tnblog.net/arcimg/hb/8901b037b36f4f5582748198721d9bc7.png) >我们发现 stress 进程的 CPU 使用率为 98.8% ###场景二:I/O 密集型进程 >这次模拟 I/O 压力 ```bash stress -i 1 --timeout 600 ``` ![](https://img.tnblog.net/arcimg/hb/f063366dc9524c808a712acfb81f353a.png) >在第二个终端运行 uptime 查看平均负载的变化情况: ```bash watch -d uptime ``` ![](https://img.tnblog.net/arcimg/hb/a5c8e4d07d0449c98dff8276789cdf80.png) >第三个终端运行 mpstat 查看 CPU 使用率的变化情况: ```bash # 显示所有CPU的指标,并在间隔5秒输出一组数据 mpstat -P ALL 5 1 ``` >从这里可以看到,1 分钟的平均负载会慢慢增加到 1.05,但 iowait 并没有升高是因为案例中stress使用的是 sync() 系统调用,它的作用是刷新缓冲区内存到磁盘中。对于新安装的虚拟机,缓冲区可能比较小,无法产生大的IO压力,这样大部分就都是系统调用的消耗了。所以,你会看到只有系统CPU使用率升高。解决方法是使用stress的下一代stress-ng,它支持更丰富的选项,比如 stress-ng -i 1 --hdd 1 --timeout 600(--hdd表示读写临时文件)。 <br/> tn>在实际中 iowait 会逐渐到达 100% >最后通过 pidstat 工具定位是哪个进程使用IO率这么高 ```bash # 间隔5秒后输出一组数据 pidstat -u 5 1 ``` ![](https://img.tnblog.net/arcimg/hb/082855dcb0f44027b6c1ca7945751dc9.png) >可以发现,还是 stress 进程导致的。 ###场景三:大量进程的场景 tn>当系统中运行进程超出 CPU 运行能力时,就会出现等待 CPU 的进程。 <br/> >我们还是使用 stress,但这次模拟的是 8 个进程: ```bash stress -c 8 --timeout 600 ``` ![](https://img.tnblog.net/arcimg/hb/89ac266fa2854025b47cb85939906365.png) >由于系统只有 1 个 CPU,明显比 8 个进程要少得多,因而,系统的 CPU 处于严重过载状态,平均负载高达 7.66 ```bash watch -d uptime ``` ![](https://img.tnblog.net/arcimg/hb/55396670a2e449ff8e040cfc197bd557.png) >接着再运行 pidstat 来看一下进程的情况: ![](https://img.tnblog.net/arcimg/hb/91a4e0d865994e68898ec07eda1939ae.png) >可以看出,8 个进程在争抢 1 个 CPU,每个进程等待 CPU 的时间(也就是代码块中的 %wait 列)高达平均 88%。这些超出 CPU 计算能力的进程,最终导致 CPU 过载。 <br/> tn>pidstat输出中没有%wait的问题,是因为CentOS默认的sysstat稍微有点老,源码或者RPM升级到11.5.5版本以后就可以看到了。而Ubuntu的包一般都比较新,没有这个问题。
欢迎加群讨论技术,1群:677373950(满了,可以加,但通过不了),2群:656732739
👈{{preArticle.title}}
👉{{nextArticle.title}}
评价
{{titleitem}}
{{titleitem}}
{{item.content}}
{{titleitem}}
{{titleitem}}
{{item.content}}
尘叶心繁
这一世以无限游戏为使命!
博主信息
排名
6
文章
6
粉丝
16
评论
8
文章类别
.net后台框架
166篇
linux
17篇
linux中cve
1篇
windows中cve
0篇
资源分享
10篇
Win32
3篇
前端
28篇
传说中的c
4篇
Xamarin
9篇
docker
15篇
容器编排
101篇
grpc
4篇
Go
15篇
yaml模板
1篇
理论
2篇
更多
Sqlserver
4篇
云产品
39篇
git
3篇
Unity
1篇
考证
2篇
RabbitMq
23篇
Harbor
1篇
Ansible
8篇
Jenkins
17篇
Vue
1篇
Ids4
18篇
istio
1篇
架构
2篇
网络
7篇
windbg
4篇
AI
18篇
threejs
2篇
人物
1篇
嵌入式
2篇
python
13篇
HuggingFace
8篇
pytorch
9篇
opencv
6篇
最新文章
最新评价
{{item.articleTitle}}
{{item.blogName}}
:
{{item.content}}
关于我们
ICP备案 :
渝ICP备18016597号-1
网站信息:
2018-2024
TNBLOG.NET
技术交流:
群号656732739
联系我们:
contact@tnblog.net
欢迎加群
欢迎加群交流技术