《锁长期等待》项目大作业-鲲鹏Devkit性能分析工具

目录

《锁长期等待》项目大作业-鲲鹏Devkit性能分析工具 1

1 调优前的准备工作 1

1.1 登录鲲鹏性能分析页面 1

1.2 MobaXterm登录SSH服务器 3

1.3 调优前准备 6

2 进入性能分析工具操作 9

2.1 全景分析 11

2.2 进程/线性能分析 12

2.3 资源调度分析 13

2.4 热点函数分析 15

2.5 优化代码 16

2.6 优化后性能检验 19

进入性能分析工具操作

一、进入性能分析工具操作

1. 选择系统性能分析

​

1. 创建工程

输入程序名称project_Zixin-选择[通用场景]-选择目标节点（服务器与环境）​

全景分析

1. 新建分析任务

输入任务名称：zixin1

选择分析对象：系统

选择分析类型：选择全景分析(未知对应问题下选择)

采样时长：60s

​

​

1. 性能页-表格模式

通过cpu的相关指标看出cpu0 或 cpu1的 用户态使用率比较高。

​

1. 内存使用情况

​

1. NUMA内存统计（是否跨节点访问记录）

​

1. 网络IO情况

​

进程/线性能分析

通过全景分析一直CPU上有压力，内存，储存IO没什么压力

1. 建立分析任务

​

1. 关键截图二：进程/线程性能分析任务结果-总览

总览页签下查看各进程的CPU使用情况，发现启动命令为 ./pthread_mutex_long 的进程的用户态使用率高，这个正好也是我们启动的测试程序。

亲和性：类似饱和，可以看到对应占用较高对应的Command就是pthread_mutex_long程序

​

资源调度分析

目的：想看CPU是怎么调度的

1. 创建任务，采样时间可以选择稍微长一点，以更好地查看调度情况

​

1. 关键截图三：资源调度分析任务结果-总览

​

1. 查看线程/线程调度

关键截图四：资源分析任务结果-进程/线程调度

​

规律：

• 没有出现被同时调度的情况
• 且两个线程分别被CPU0和CPU1所调度

推论：两个CPU之间有一个相互等待的行为，发现在采样期间两个线程之间的调度没有交集，没有平衡的相互交替运行，我们可以推断两个线程可能在抢占某个资源

热点函数分析

目的：查看源代码，CPU使用率较高往往是由于热点函数所造成的

1. 创建任务

​

1. 关键截图五：热点函数分析任务结果-总览

测试程序的热点函数是 Func

​

1. 关键截图六：热点函数分析任务结果-热点函数源码

通过对热点函数的源码分析，发现其中有一段业务逻辑并不涉及并发的场景，并且这块业务逻辑是Func函数中热度最高的，完全可以移到锁的范围之外去。

点击Func进入源代码，图中为问题代码行

​

​

优化代码

1. 回到MobaXterm，Ctrl+C停止代码运行

进入/home目录，修改程序pthread_mutex_long.c

​

1. 右键点击程序打开

​

可以看到g_count与N使循环次数极多，耗时长

1. 优化实现：将代码移动到后面

关键截图七：代码优化前后对比

优化前：

​

修改后：

​

1. 保存修改重新上传编译：

​​

优化后性能检验

1. 再次创建资源调度任务检查优化后的代码

​

1. 关键截图八：代码优化后重新启动，资源分析任务结果-进程/线程调度

测试程序的两个线程会平稳的进行，不会存在长时间的等待。

切换时间减少：

​

两个线程会平稳的进行：

​