前言
本文的上一篇为: https://www.cnblogs.com/aoximin/p/16861797.html
该文为dotnet-dump 和 procdump 的实战介绍一下。
正文
现在很多情况下去抓取dotnet 运行的信息一般都是适用 procdump 或者 直接使用dotnet-dump
这个procdump 有什么用呢？
根据 ProcDump 帮助，下面是必须使用的开关：
-M：当内存提交超过或等于指定值时触发核心转储文件生成 (MB)
-n：退出前要写入的核心转储文件数 (默认值为 1)
-s：连续几秒钟写入转储文件 (默认值为 10)
-d：将诊断日志写入 Syslog
-p：进程的 PID
这个的好处就是有时候突然间内存升高，其实就是多了一个监控的作用。
我记得以前每次用dotnet-dump的时候，我让运维写了一个脚本，当内存到达多少或者cpu到达多少的时候执行一些dotnet-dump 这个命令。
我们知道一般抓取需要连续抓取，那么我们用上一篇的例子抓一下。
procdump -pgid 108232 -n 2 -c 50 -s 3
上面就是说cpu到达50%并持续时间3秒，那么就执行抓取操作，一共抓取两次，相隔10秒。
这个procdump 抓取的内容在workdirection下面，也就是自己的工作目录下面。
那么抓取一次。
运行的时候一直在monitor，看到了吧。
然后执行慢查询:
这样就ok了。
然后用dotnet-dump 去解析就好了。
如果使用dotnet-dump 的话:
这个是安装:
dotnet tool install -g dotnet-dump
然后你也可以这么收集:
查看正在运行的dotnet core：
dotnet-dump ps
然后：
dotnet-dump collect -p xxx
根据进程号收集就好了。 但是这样只能手动，procdump 可以做到监听。
如果是偶发性的用procdump 比较好，比如不是，那么用dotnet-dump就好了。
然后dotnet-dump 分析的话，举个例子：
dotnet-dump analyze /tmp/coredump.manual.1.108232
然后其实和lldb 没有什么区别，其实lldb 更为强大而已，带调试功能和查看非托管的功能，而dotnet-dump 查看托管问题。
可以看到命令差不多。
把上篇文章的上半段内存问题给演示下：
dumpheap -stat
统计一下:
这个 string 很大，然后查看大对象:
dumpheap -stat -min 85000
大于8.5m string 有 365个。
查看一下对象堆，并且活跃的，可以理解为没有被GC标记的吧：
dumpheap -mt 00007f4908c80f90 -min 85000 -live
这里就有4个了。
那么查看其中一个就好。
95m差不吧。
然后看下其位置：gcroot -all 00007f48b6458178
这样就找到了代码的位置。
结
该系列逐步补充，补的是一些排查技巧和一些原理，为什么这样抓取，为什么能抓到之类的，怎么排查更快之流。
持续更新。。。。。。。
标签：core,procdump,查看,dump,抓取,重新整理,内存,dotnet From： https://www.cnblogs.com/aoximin/p/16868010.html