目录
- 1、升级环境,安装stress-ng工具
- 2、进程上下文切换-模拟场景
- 3、进程上下文切换-top命令
- 4、vmstat 1 命令 -每隔1s显示一次数据
- 5、pidstat -w 3 -找有问题的进程id
- 6、总结
- 7、分析过程-找到有问题的进程
正文
1、升级环境,安装stress-ng工具
# 安装epel源,更新系统 yum install -y epel-release.noarch && yum -y update # 安装stess-ng 的工具 yum install -y stress-ng
2、进程上下文切换-模拟场景
该命令会启动N*10个进程,再只有N个核的系统上,会产生大量的进程切换,模拟进程间竞争CPU的场景
(( proc_cnt = `nproc`*10 )); stress-ng --cpu $proc_cnt --pthread 1 --timeout 150
# nproc 这个命令可以获得服务器cpu的数量
# (( proc_cnt = `nproc`*10 )); 把cpu核的数量乘以10倍,给变量proc_cnt
# --cpu $proc_cnt $proc_cnt shell编程中的变量引用
# --pthread 每个进程有多少个线程
# --timeout 超时时间,在命令执行多长时间之后自动结束
3、进程上下文切换-top命令
top命令:load值一直在增加,而且增长的非常大
cpu的us+sy差不多百分百,us较高,sy较低,running用户多
如下图所示:
在运行的时段里,loadaverage 有持续上升,cpu被100%使用 us + sy + si,内存信息变动不大,进程结束后可用内存恢复,回收正常。
上下文切换多
4、vmstat 1 命令 -每隔1s显示一次数据
- procs: r显示多少进程在等待,b显示多少进程在不可中断的休眠
- menory:是我拍的显示多少块被换出磁盘,free显示剩下的空闲块,buff正在被用作缓冲区的块,cache正在被用作操作系统的缓存
- swap:现在交换活动,si每秒有多少块正在被换入内存,so每秒有多少块被换出到磁盘
- io:显示了多少块从块设备读取(bi)和写出(bo),通常反应了硬盘IO
- system:显示每秒中断(in)和上下文切换(cs)的数量
- cpu:显示所有的cpu时间花费在各类操作的百分比,包括执行用户代码(非内核),执行系统代码(内核),空闲以及等待IO
- proces中r列非常大的数据,说明有非常多的进程在抢CPU的资源
- free数据变小,说明内存有一部分被使用
- system in中断有上升,cs上下文切换数据明显增大
5、pidstat -w 3 -找有问题的进程id
6、总结
结论
- 1、top: load值一直在增加,而且增长的非常大
- 2、top:CPU的 us + sy ≈ 100%,us较高,sy较低
- 3、vmstat: procs的r 就绪队列长度,正在运行和等待的CPU进程数很大
- 4、vmstat: system的in(每秒中断次数) 和 cs(上下文切换次数) 都很大
- 5、vmstat:free、buff、cache变化不大
- 6、pidstat: nvcswch/s 非自愿上下文切换在逐步升高
7、分析过程-找到有问题的进程
当你的服务器,使用top命令发现,系统负载比较高,所有的cpu的使用率接近或等于 100%,我们要排查问题,vmstat 1 , 结果我们看到有procs 中r列 有大量数据,说明我们有大量进程在竞争cpu的资源。--------可能服务器的cpu数量不够, 也可能是 进程启动的太多
vmstat 我们还看 system中 cs 比较高 --------肯定有大量的上下文切换
但是,此时,我并不知道,是哪个进程导致 抢占cpu,-----找具体是哪个进程
==== 应该是某个经常有大量的上下文切换,而导致的cpu使用率过高,系统负载过高的问题
---问题的关键点,找到具体的进程
pidstat -w 3 看到具体的 上下文切换的数据比较大的进程。-------得到具体进程 和进程id
标签:--,vmstat,切换,进程,上下文,cpu From: https://www.cnblogs.com/xfbk/p/17644767.html