如果要分析 Linux上的 .NET程序 CPU 爆高，按以往的个性我肯定是抓个 dump 下来做事后分析，这种分析模式虽然不重但也不轻，还需要一定的底层知识，那有没有傻瓜式的 CPU 爆高分析方式呢？
相信有很多朋友知道 B站713事件，最终就是用 perf 找到了那个让 cpu 100% 的 lua 函数，截图如下：
这里我们也借助 perf 这款工具实现 .NET程序的 cpu 爆高洞察， perf 就不过多介绍了，它是Linux系统中提供的一款性能分析工具，类似 Windows 的 ETW 跟踪，所以对他的了解是非常重要的。
这里要注意的是我们并不直接使用，而是用微软提供的基于 perf 的高层封装工具 perfCollect，它不仅能收集 perf 能收集的事件，还能收集 .NET 中的 EventSource 事件，简直是福音哈。
为了能够让 CPU 爆高，我们故意让其中一个方法死循环，一个方法运行一段时间正常结束，参考代码如下：
namespace ConsoleApp1
{
internal class Program
{
static void Main(string[] args)
{
Task.Run(() =>
{
Test1();
});
Task.Run(() =>
{
Test2();
});
Console.ReadLine();
}
static void Test1()
{
int i = 1;
bool b = false;
while (i > 0)
{
b = !b;
}
}
static void Test2()
{
for (int i = 0; i < short.MaxValue; i++)
{
}
}
}
}
代码有了就可以 publish 到 centos 上，接下来在 /etc/profile 中增加一个环境变量 export COMPlus_PerfMapEnabled=1 ，目的是让 RIP 能够成功解析到 C# 的方法名，截图如下：
有了这些前置基础，接下来就是把程序跑起来，用 htop 观察下 CPU 的利用率。
[root@localhost data2]# vim /etc/profile
[root@localhost data2]# source /etc/profile
[root@localhost data2]# ls
ConsoleApp1 ConsoleApp1.deps.json ConsoleApp1.dll ConsoleApp1.pdb ConsoleApp1.runtimeconfig.json
[root@localhost data2]# dotnet ConsoleApp1.dll
刚才也说了 PerfCollect 是微软提供的一款工具，集成了 perf + LTTng 两块，前者用于捕获Linux系统级事件，后者用于捕获 CoreCLR 以及 EventSource 事件，接下来就是下载，赋权限，安装。
[root@localhost data3]# curl -OL https://aka.ms/perfcollect
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:00:02 --:--:-- 0
100 68590 100 68590 0 0 17540 0 0:00:03 0:00:03 --:--:-- 72658
[root@localhost data3]# chmod +x perfcollect
[root@localhost data3]# sudo ./perfcollect install
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
epel/x86_64/metalink | 28 kB 00:00:00
* base: ftp.sjtu.edu.cn
* epel: d2lzkl7pfhq30w.cloudfront.net
* extras: mirror.lzu.edu.cn
* updates: mirror.lzu.edu.cn
base | 3.6 kB 00:00:00
docker-ce-stable | 3.5 kB 00:00:00
extras | 2.9 kB 00:00:00
packages-microsoft-com-prod | 1.5 kB 00:00:00
updates | 2.9 kB 00:00:00
Package perf-3.10.0-1160.92.1.el7.x86_64 already installed and latest version
Package zip-3.0-11.el7.x86_64 already installed and latest version
Package unzip-6.0-24.el7_9.x86_64 already installed and latest version
Nothing to do
LTTng already installed.
安装好之后进行 10s 采集，采集完之后就会生成一个 ConsoleApp.trace.zip 文件，输出如下：
[root@localhost data3]# ./perfcollect collect ConsoleApp -collectsec 10
Collection started. Collection will automatically stop in 10 second(s). Press CTRL+C to stop early.
...STOPPED.
Starting post-processing. This may take some time.
Generating native image symbol files
...FINISHED
Saving native symbols
...FINISHED
Resolving JIT and R2R symbols
...FINISHED
Exporting perf.data file
...FINISHED
Compressing trace files
...FINISHED
Cleaning up artifacts
...FINISHED
Trace saved to ConsoleApp.trace.zip
最后把 ConsoleApp.trace.zip 复制到 Windows 平台上用 PerfView 分析。
说句良心话，Perfview 真的是太强大了，什么文件都能从中提取有用信息，比如 .dmp，.nettrace 还有这里的 .zip ，用 Perfview 打开 zip 之后，双击 CPU Stacks 选项，找到我们的 PID 进程即(.NET ThreadPool)，截图如下：
[root@localhost data3]# ps -ef | grep dotnet
root 6027 3171 99 23:33 pts/1 00:02:01 dotnet ConsoleApp1.dll
root 6529 5240 0 23:35 pts/2 00:00:00 grep --color=auto dotnet
双击打开之后，去掉 GroupPats 信息，可以看到占比最高的是 Program::Test1() 方法。
有朋友可能要问这个信息怎么解读呢？其实非常简单，perf 也是按照 1ms 采样一次的方式，所以 10s 的样本数： 1w =10 * 1000。
从上图中可以看到,总的采样到了 9999 个样本，其中 Program::Test1() 占据了 9993，占比高达 99.9%，到这里我们就定位出了原来这个函数就是 hot 函数。
不知道大家发现没有，在 Windows 上很容易监控的东西，在 Linux 上就要麻烦的多，其实很容易理解，Windows 是微软的, .NET 也是微软的，自然是一等公民的存在。
