重新整理 .net core 实践篇 ———— linux上性能排查 [外篇]

前言该文的前置篇为:
https://www.cnblogs.com/aoximin/p/16839830.html
本文介绍性能排查 。
正文上一节是出现错误了 , 如何去排查具体问题 。
这一节介绍一下性能排查 。
还是上文的例子作为演示:https://buggyambfiles.blob.core.windows.net/bin/buggyamb_v1.1.zip
项目地址:https://github.com/ahmetmithat/buggyamb
本文实验的还是lldb 和 sos 。
对比一下cpu 情况 。
实验实施条件:

重新整理 .net core 实践篇 ———— linux上性能排查 [外篇]

文章插图
请求前:
重新整理 .net core 实践篇 ———— linux上性能排查 [外篇]

文章插图
点击请求后:
重新整理 .net core 实践篇 ———— linux上性能排查 [外篇]

文章插图
这样对比还是很大的哈 。
那么我们来看下啥子情况吧 。
查看进程名:
重新整理 .net core 实践篇 ———— linux上性能排查 [外篇]

文章插图
那么当cpu 高的时候进行抓取 , 一般抓取两个 , 两个间隔10秒左右 。
为什么抓取两个呢? 因为好对比作用 , 更好定位 , 这个多实验实验就清楚了 。
抓取命令:
/usr/share/dotnet/shared/Microsoft.NETCore.App/3.1.30/createdump 108232 -f /tmp/coredump.manual.1.%d/usr/share/dotnet/shared/Microsoft.NETCore.App/3.1.30/createdump 108232 -f /tmp/coredump.manual.2.%d两个命令间隔10秒 。
我们知道这个createdump 是 dotcore runtime 自带的 。
那么怎么知道他的位置呢?
重新整理 .net core 实践篇 ———— linux上性能排查 [外篇]

文章插图
这样可以查找到位置 。
重新整理 .net core 实践篇 ———— linux上性能排查 [外篇]

文章插图
可以看到10秒后内存升高了 。
那么就可以上一章的内容了 , 进入lldb 。
lldb --core coredump.manual.1.108232
然后查看线程:
重新整理 .net core 实践篇 ———— linux上性能排查 [外篇]

文章插图
看这个线程 , 发现和其他GC mode 不一样 。
那么就有一个东西需要科普了 , 分别是cooperative 和 preemptive 。
如果线程的 GC 模式设置为 “抢占” , 则表示 GC 可以随时挂起此线程 。相比之下 , 协作模式意味着 GC 必须等待线程切换到抢占模式 , 然后才能挂起它 。当线程运行托管代码时 , 它处于协作模式 。这句话什么意思呢? 就是说这个线程在占用cpu的意思 。那么cpu 高就应该看这个东西了 。
setthread 14 然后切到这个线程 。这里就不解释了 , 都是上一章的东西 。
然后调用一下clrstack 。
重新整理 .net core 实践篇 ———— linux上性能排查 [外篇]

文章插图
然后来看一下干了什么?
重新整理 .net core 实践篇 ———— linux上性能排查 [外篇]

文章插图
感觉是在做字符串拼接啊 。
那么这个时候是会造成cpu高和内存高的 , 那么要证明自己的猜想 。
使用dso 查看一下 。
Displays all managed objects found within the bounds of the current stack.
重新整理 .net core 实践篇 ———— linux上性能排查 [外篇]

文章插图
看下这个string , 为什么看这个呢?因为这个string , 和System.Data.DataRow 比较近 , 这个可以学习汇编可能跟容易理解 。
重新整理 .net core 实践篇 ———— linux上性能排查 [外篇]

文章插图
查看了一下这个倒是有100m 。
读取一下内存 , 看下里面是什么?
重新整理 .net core 实践篇 ———— linux上性能排查 [外篇]

经验总结扩展阅读