当前位置：首页 > news >正文

性能分析-CPU知识

news 来源：原创 2024/5/19 10:08:22

CPU知识

cpu组成

查看cpu信息：

top命令中 cpu相关：

top命令看到系统负载： CPU负载 + IO负载

上下文： CPU的寄存器和程序计数器----在cpu的控制器中

实战演示分析

top命令分析

arthas工具

进程上下文切换高的问题分析

stress-ng 工具定位

分析

top

vmstat

pidstat -w 1

线程上下文切换的问题分析

stress-ng 工具定位

分析

top

vmstat

pidstat -w 1

IO密集型导致服务器负载高

stress-ng 工具定位

分析

top

vmstat 1

iostat -dx 1

监控平台

grafana + promethues 监控模板界面不显示数据

CPU知识

选择：架构、核、主频

cpu组成

控制单元、计算单元、存储单元

查看cpu信息：

top
lscpu
cat /proc/cpuinfo

top命令中 cpu相关：

top命令中的进程列表中，是根据cpu的使用率从高到低。所以使用top进行性能分析时，如果 cpu使用率高，可以首先分析top命令中进程列表中 cpu使用率最高的第一个进程。
us\sy 非内核态(用户态)\内核态(系统态)
- us：逻辑运算
- sy：底层计算
- 如果现在 top命令中，cpu使用率高的第1个进程，是一个应用程序。此时再看 us、sy。
  - us高：应该是应用程序的逻辑运算频繁 ------代码有问题
- 如果现在top命令中，cpu使用率高的第1个进程是一个数据库程序。此时再看 us、sy。
  - us高： sql语句执行逻辑很复杂 -----sql有问题
  - sy高：读写磁盘操作

top命令看到系统负载： CPU负载 + IO负载

sys高， =====> 怀疑===>上下文切换高 ======>pidstat====>自愿上下文切换高------可能是获取不到足够的资源，----内存不足
sys高 =====》怀疑 =====》上下文切换=====》pidstat=====》非自愿上下文切换高 -----cpu不够用
us高 ====》业务逻辑有关 -----实现上存在、FGC、 CPU密集计算
si高 ====》抢占资源 wa高 ===》等资源 -----可能是内存，也可能是网络资源、外设资源、磁盘资源太慢

上下文： CPU的寄存器和程序计数器----在cpu的控制器中

上下文切换发生在cpu的控制器中。其实就是 cpu控制器中的指令的切换。

CPU上下文的切换，先保存前一个指令的资源到内核中，然后加载新的指令的资源，执行新的指令

这个过程有保存老的，加载新的，所以它会占用CPU的时间。如果占用的总时间长，到cpu的用与计算的时间就少了。所以cpu运算速度就变慢，处理的响应时间就变长了。

切换的指令，可以是同一个进程的，也可以是不同进程的

同一个进程中上下文切换。
- 进程是资源的拥有者。
- 同一个进程中，不同线程之间的切换。只需要保存线程的私有的资源即可
不同进程之间，上下文切换。
- 保存前一个进程的资源，然后打开新进程的资源。

实战演示分析

现在讲的CPU，cpu是硬件设备。要进行性能分析可以使用性能分析命令，也可以使用监控平台。

先用命令分析
再用监控平台来分析

把xxxxx项目启动

对获取验证码接口进行性能测试

top命令分析

top进程列表中， cpu使用率最高的java进程
- 知道 java进行的 pid
- ps -ef |grep pid 找找到具体java进程 -----判断出，到底是哪个java进程，导致的cpu使用
cpu的总的使用率数据中，显示总和接近100%， us态是最高的
- 代码逻辑有问题
结论： xxxxx项目，在获取验证码接口上，存在性能问题，代码逻辑可能有问题。

arthas工具

是阿里开源的 java项目的性能分析工具。

定位：
- arthas：下载到 xxxx项目机器上 curl -O https://arthas.aliyun.com/arthas-boot.jar
- 使用 java -jar arthas-boot.jar 启动arthas
  - 显示出，所有的java进程列表
  - 选择你要分析的java进程的id的序号回车，就自动连接到你要连接到java进程
  - 查看帮助信息thread --help

thread -n 数字 ------获取到了 cpu使用率最高的几个线程栈信息
- 如果你看不懂，你把这个线程栈信息，给 java开发人员，让他们定位。
- 自己看线程栈信息，找到项目工程的代码类和行
  - at
  - com.lemon.lemon_erp.controller.CodeController.getCode(CodeController.j ava:67)

进程上下文切换高的问题分析

stress-ng 工具定位

进程：在一台机器上有多个进程

使用 stress-ng 工具，来模拟产生大量的进程，然后相互竞争，造成性能现象，模拟在企业服务器中多进程的情况。

yum install epel-release.noarch

yum update -y

yum install stress-ng -y

命令 nproc 获取系统cpu的数量

((proc_cnt = `nproc`*10)); stress-ng --cpu $proc_cnt --pthread 1 --timeout 120s

分析

top

进程列表中，cpu使用率最高的一些进程的名称相同； cpu的 us态值最高 sy也有增大； loadaverage 非常大。
- 进程名称相同，怀疑是在抢cpu资源----想到 vmstat

vmstat

procs中r队列的值，有明显的数据变化。
有大量的进程在抢占cpu资源。 -------cpu不够，是性能瓶颈。
内存中，free有稍微变少，cache有变大，buff基本没变
bi bo si so 没有明显的变化
system中的 in 变化比较小， cs变化非常大。-----上下文切换非常大。

pidstat -w 1

cswch/s 自愿上下文切换要大一些 nvcswch/s 也有明显的数，相对来说小一些。

当系统出现了进程上下文过多导致的性能问题，通过top命令和vmstat命令和pidstat命令，看到现象就如上。

这个问题，怎么解决？

加cpu，但是实际中，加cpu数量，是不方便。
减少进程（迁移一些进程到另外的服务器上、或者调整项目代码配置，减少启动的进程数量）

线程上下文切换的问题分析

一个进程：就是一个程序、一个服务、一个项目，进程是资源的拥有者。

线程：是进程的工作者。一个进程是可以有多个线程的。

线程上下文切换：

同一个进程中，多个线程之间的切换

不同进程间，线程的切换 ------类似进程切换

stress-ng 工具定位

stress-ng --cpu `nproc` --pthread 10 --timeout 120

分析

top

系统负载升高、CPU的使用情况中 us和sy都有值、si也有值，sy要比us大。进程列表中先了多个项目的名称。

vmstat

proc中 r列有明显的数据变化，b列没有变化，free有变小，cache变大，in、cs有数据变化，但是 cs变化的很明显(上下文切换)。

pidstat -w 1

看到每一个线程的 cswch/s 自愿上下文切换的数据都比较大，每个线程的非自愿nvcswch/s上下文切换数据比较小的。

	进程上下文切换	线程上下文切换
top	us大，sy小	us小，sy大
vamstat 1	proc列的r数据大、cs数据大	proc列的r数据大、cs数据大
pidstat -w 1 ，	总的进程的自愿上下文大，每个进程的自愿上下文小，每个进程的非自愿上下文切换大。	每个线程的自愿上下文切换是大的，非自愿上下文切换小

这种问题怎么解决？

少启动一些线程：
- 修改进程中，启动的线程数的配置 ------ 最大值，由服务所在的机器或容器的CPU核数来定
- 在服务器上，少启用一些服务\进程，迁移一些进程到其他服务器上面。

IO密集型导致服务器负载高

系统负载高，由两部分组成： CPU负载高、 IO负载高 io负载高，
top命令看得时候，cpu的使用率中 wa 值
如果 CPU使用率中wa值比较大，这种情况大概率就是 IO性能问题
io负载：磁盘负载、网络负载、外设负载
- 如果是网络负载慢：可能就是网卡或者是带宽
  - 网卡：一般情况下都是千兆网卡 ------一般情况下，网卡速度不会成为瓶颈
- 外设：
  - 磁盘：读写使用率 IOPS 模拟，系统IO使用率高，导致的性能瓶颈的分析
模拟，系统IO使用率高，导致的性能瓶颈的分析
- 什么现象，说明磁盘的io成为了性能瓶颈？

stress-ng 工具定位

stress-ng -i 6 --hdd 1 --timeout 120

分析

top

sy、wa、si 这三个值，跳跃性的成为最大值。

sy cpu的内核进程计算读写磁盘是发生在内核中
wa 等待数据
si 软中断

vmstat 1

proc的r队列有变化不明显； free表小，cache 变大了， bi、bo有明显的数据

bi bo 是磁盘操作-----怀疑是磁盘瓶颈

iostat -dx 1

await有明显的数据，说明有明显的磁盘等待。

使用这个命令不要过于频繁或时间过长。执行这个命令很明显的等待，操作会很卡，持续操作的话，可能导致机器宕机。

问题解决办法

磁盘成为了瓶颈
- 换磁盘：应用服务器换固态硬盘
- 减少IO操作：应用服务器，写日志，是应用服务最常见的磁盘操作
  - 减少日志：提高日志级别，日志级别越高，日志量越少。
  - 日志文件拆解：如根据日志文件大小拆解
- 数据库服务器的磁盘瓶颈

监控平台

监控服务器硬件资源： grafana + Prometheus + node_exporter

grafana
prometheus 时序数据
node_exporter: Prometheus收集硬件资源的收集器
- 如果你想要收集信息，就选择用不同的
- exporter exporter不同，就可以收集不同的资源（硬件资源、服务资源）

grafana、Prometheus，不会安装在被监控服务器上。 exporter 会安装到被监控的机器上。要收集多个机器，每个机器上都放置 exporter

node_exporter的默认端口：浏览器http协议可以访问端口 9100

启动 ./node_exporter

Prometheus可浏览器http协议访问的端口： 9090

配置文件 prometheus.yml 要注意格式

- job_name: 'node_exporter'
static_configs:
- targets: ['192.168.130.133:9100']

./prometheus

启动grafana： systemctl restart grafana-server

http://grafana的ip:3000 admin admin

选择添加 Prometheus数据源

注意：数据源添加url： http://prometheus的ip:9090

引入模板： import 12884

注意：数据源，要选择你上面添加的数据源的名称

grafana + promethues 监控模板界面不显示数据

Prometheus 与 node_exporter机器网络不通
Prometheus的机器的时间与 node_expoter机器的时间相差特别大
- 隔8小时把grafana的模板界面右上角的时间拉长8小时以上--出现数据
界面模板的界面左上角信息没有出来 ---可以手动填，不是所有的都会带出来
有修改 hosts文件（系统名未改，大部分公司已经改了的）
- /etc/hosts文件中
  - 没有填写主机名网络请求时，有的会要读取这个文件中主机名，读不到会导致网络延迟非常大。

搭建环境详见：Linux集群监控部署: prometheus 普罗米修斯 + Grafana（超详细）_监控普罗米修斯和gra-CSDN博客文章浏览阅读1.1w次，点赞12次，收藏130次。前言之前我们有用到top、free、iostat等等命令，去监控服务器的性能，但是这些命令，我们只针对单台服务器进行监控，通常我们线上都是一个集群的项目，难道我们需要每一台服务器都去敲命令监控吗？这样显然不是符合逻辑的，Linux中就提供了一个集群监控工具 – prometheus。..._监控普罗米修斯和grahttps://blog.csdn.net/weixin_43865008/article/details/118946362