统计的方法定位问题是比较快的 。
两个里面查看统计：
dumpheap -stat第一个:
![重新整理 .net core 实践篇 ———— linux上性能排查 [外篇]](http://img.zhejianglong.com/231019/14304340X-16.jpg)
文章插图
第二个:
![重新整理 .net core 实践篇 ———— linux上性能排查 [外篇]](http://img.zhejianglong.com/231019/14304332N-17.jpg)
文章插图
发现这个system.string 两个都很大，且变多了 ， 而DataRow 也不少 。
但是这里涨的又不成比例，比如这里对象涨了几百，但是内存涨了200m 。
这个时候可能就怀疑 大型对象堆 (LOH) 的问题了 。
那么查一下大于85000字节的数据统计 。
dumpheap -stat -min 85000
第一个：
![重新整理 .net core 实践篇 ———— linux上性能排查 [外篇]](http://img.zhejianglong.com/231019/1430432J8-18.png)
文章插图
第二个:
![重新整理 .net core 实践篇 ———— linux上性能排查 [外篇]](http://img.zhejianglong.com/231019/14304355Y-19.png)
文章插图
运行 dumpheap -stat -min 85000 -live 。此命令仅显示根于某处的对象 。在此示例中，只有正确的对象实例 string 位于 LOH 中 。
-live 就是活跃的意思 ， 也就是应用程序正在使用的，不会被GC的 。
![重新整理 .net core 实践篇 ———— linux上性能排查 [外篇]](http://img.zhejianglong.com/231019/14304364E-20.png)
文章插图
这里有4个，看下这4个是啥吧 。
![重新整理 .net core 实践篇 ———— linux上性能排查 [外篇]](http://img.zhejianglong.com/231019/14304360E-21.png)
文章插图
然后查看一个的内存：
![重新整理 .net core 实践篇 ———— linux上性能排查 [外篇]](http://img.zhejianglong.com/231019/143043MV-22.png)
文章插图
这样就定位到了 。
但是还得查看一下这个对象位置在哪？ 怎么办呢？用SOS的命令：gcroot
![重新整理 .net core 实践篇 ———— linux上性能排查 [外篇]](http://img.zhejianglong.com/231019/143043A51-23.png)
文章插图
这个是源代码内部的，看的不清楚 。
使用-all
![重新整理 .net core 实践篇 ———— linux上性能排查 [外篇]](http://img.zhejianglong.com/231019/143043KQ-24.png)
文章插图
这样就直接定位到行了 。
原因就是string+=string，等于String.Concat(System.String[])造成大量string 对象复制堆积 。
结下一节介绍procDump 和 dotnet-dump，procDump 这个挺好用的，dotnet-dump 更为方便 。基本是必学的 。
【重新整理 .net core 实践篇 ———— linux上性能排查 [外篇]】
推荐阅读
- 在 .NET 7上使用 WASM 和 WASI
- 重新整理 .net core 实践篇 ———— linux上排查问题实用工具 [外篇]
- .NET 7 中 LINQ 的疯狂性能提升
- 两种 .Net Core 3.0 对 MongoDB 的多条件查询操作
- 螃蟹断掉的腿，还能重新长出来吗?
- .NET性能优化-复用StringBuilder
- .net 温故知新：【8】.NET 中的配置从xml转向json
- 来啦来啦｜开源 * 安全 * 赋能 - .NET Conf China
- 如何在.NET程序崩溃时自动创建Dump？
- .NET Conf 2022 – 11 月 8 日至 10 日