目录

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