鲲鹏Devkit性能分析工具课堂笔记—第三讲：《锁长期等待》项目大作业解析

华为账号hw_Zixin，严禁直接盗用侵权！

一、调优前的准备工作

登录鲲鹏性能分析页面

1.   在鲲鹏社区申请远程实验室操作系统选择OpenEuler（含有VPN与性能调优工具账号）。鲲鹏社区-官网丨凝心聚力 共创行业新价值https://www.hikunpeng.com/zh/developer/devkit
2. 在收到申请成功邮件后根据邮件手册指引链接VPN（具体账号与密码见邮件信息）​
3. 访问邮件中的代码迁移工具WEB地址，输入邮件提供的用户名与密码登录性能分析工具登陆界面​
4. 登陆成功进入性能调优工具页面​

  MobaXterm登录SSH服务器

1.  打开Session ​
2. 选择SSH ​
3. 新建用户 ​
4. 创建用户 ​ 
5. 根据邮件提供信息输入用户名与密码 ​
6. 保存确认 ​
7. 输入IP地址，选择刚刚创建好的用户 ​
8. 登陆成功 ​

调优前准备

1. 打开网页，找到测试程序 ：pthread_mutex_long.c ，复制里面的内容到本地同名的文件里devkitdemo/Hyper_tuner/testdemo/lock at main · kunpengcompute/devkitdemo · GitHub
2. 在本地电脑新建一个文件“pthread_mutex_long.c”，将代码复制粘贴进去
3. 本地电脑通过ssh工具（如：MobalXtem）将pthread_mutex_long.c上传到远程实验室的服务器上

4.  将文件保存到远程实验室的服务器上的/home目录

   mv -f "/root/pthread_mutex_long.c" "/home/pthread_mutex_long.c

   

5. 进入home目录，确定文件已经存放在该文件夹
6. 授权文件：chmod 777 pthread_mutex_long.c
7. 编译程序：gcc -g pthread_mutex_long.c -o pthread_mutex_long -lpthread -lm && chmod 777 pthread_mutex_long
8.  绑核启动：taskset -c 0-1 ./pthread_mutex_long 二、

二、程序性能分

全景分析

新建分析任务

• 输入任务名称：zixin1
• 选择分析对象：系统
• 选择分析类型：选择全景分析(未知对应问题下选择)
• 采样时长：60s
• 性能页-表格模式

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

进程/线性能分析

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

进程/线程性能分析任务结果-总览

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

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

资源调度分析

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

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

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

规律：

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

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

热点函数分析

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

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

测试程序的热点函数是 Func

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

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

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

 

 优化代码

• 回到MobaXterm，Ctrl+C停止代码运行，进入/home目录，修改程序pthread_mutex_long.

  

• 右键点击程序打开

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

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

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

优化前：

 修改后：

 保存修改重新上传编译：

 优化和性能检验

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

关键截图八：代码优化后重新启动，资源分析任务结果-进程/线程调度，测试程序的两个线程会平稳的进行，不会存在长时间的等待。