使用dotnet-dump 查找 .net core 3.0 占用CPU 100%的原因

  这篇文章介绍了3个工具


dotnet-counters: 实时统计runtime的状况, 包括 CPU、内存、GC、异常等

dotnet-trace: 类似性能探测器

dotnet-dump: 程序崩溃时使用该工具


  这次使用的是dotnet-dump, 即使程序没有崩溃, 也可以dump程序快照, 用于分析




实验环境


ubuntu-16.04.5-desktop-amd64

SDK 3.0.100-preview6-012264




1. 新建一个简单Console程序(只能是 .net core 3.0的程序, 不支持 .net core 2.2), 模拟CPU占用100%的情况



mkdir NetCoreDumpTest && cd NetCoreDumpTest dotnet new console



编辑Program.cs



namespace NetCoreDumpTest { using System; using System.Threading.Tasks; class Program { static void Main(string[] args) { Task.Factory.StartNew(() => PrintNumber("Print", 5)); Console.WriteLine("Press any key to exit."); Console.ReadKey(); } static void PrintNumber(string message, int startNumber) { var number = startNumber; while (true) Console.WriteLine($"{message} {number++}"); } } }





2. 安装dotnet-dump



dotnet tool install --global dotnet-dump --version 1.0.4-preview6.19311.1



提示



If you are using bash, you can add it to your profile by running the following command: cat << \EOF >> ~/.bash_profile # Add .NET Core SDK tools export PATH="$PATH:/home/****/.dotnet/tools" EOF You can add it to the current session by running the following command: export PATH="$PATH:/home/****/.dotnet/tools" You can invoke the tool using the following command: dotnet-dump Tool 'dotnet-dump' (version '1.0.4-preview6.19311.1') was successfully installed.



建议将 $HOME/.dotnet/tools加入到PATH, 好吧, 照着做吧, 记得使用下面的命令使设置立即生效



source ~/.bash_profile





3. 使用 dotnet NetCoreDumpTest.dll 启动我们的问题程序, 然后使用  ps -ef | grep dotnet  查看程序的进程ID, 可以看到进程ID是 3411



ps -ef | grep dotnetz*****e 3411 1464 22 07:51 pts/8 00:00:59 dotnet NetCoreDumpTest.dll z*****e 3431 2935 0 07:55 pts/9 00:00:00 grep --color=auto dotnet



针对进程3411, 我们还需要知道是哪个线程占CPU, 使用 top -Hp 3411 可以列出所有线程, 由于top每隔3秒刷新一次, 所以可能需要多观察几秒才能看到具体是哪个线程占用CPU比较高, 这里我们可以看到是PID=3418的线程(Linux的进程ID和线程ID请自行了解一下).



top -Hp 3411 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3418 z*****e 20 0 2997700 29060 22400 R 10.3 1.4 0:20.68 dotnet 3411 z*****e 20 0 2997700 29060 22400 S 0.0 1.4 0:00.11 dotnet 3412 z*****e 20 0 2997700 29060 22400 S 0.0 1.4 0:00.02 dotnet 3413 z*****e 20 0 2997700 29060 22400 S 0.0 1.4 0:00.00 dotnet 3414 z*****e 20 0 2997700 29060 22400 S 0.0 1.4 0:00.00 dotnet 3415 z*****e 20 0 2997700 29060 22400 S 0.0 1.4 0:00.01 dotnet 3416 z*****e 20 0 2997700 29060 22400 S 0.0 1.4 0:00.00 dotnet 3417 z*****e 20 0 2997700 29060 22400 S 0.0 1.4 0:00.00 dotnet 3421 z*****e 20 0 2997700 29060 22400 S 0.0 1.4 0:00.00 dotnet





获取dump, 只能正对进程进行dump, 所以我们输入的是 3411



dotnet-dump collect -p 3411 Writing minidump with heap to /tmp/core_20190623_075649 Complete





4. 分析


dotnet-dump analyze core_20190623_075649


使用clrthreads 查看所有线程



>clrthreads ThreadCount: 4 UnstartedThread: 0 BackgroundThread: 3 PendingThread: 0 DeadThread: 0 Hosted Runtime: no Lock DBG ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Count Apt Exception 0 1 d53 0000000001307D80 20020 Preemptive 0000000000000000:0000000000000000 0000000001306450 1 Ukn 4 2 d57 000000000135BBD0 21220 Preemptive 0000000000000000:0000000000000000 0000000001306450 0 Ukn (Finalizer) 6 3 d59 00007F666C0009F0 1020220 Preemptive 0000000000000000:0000000000000000 0000000001306450 0 Ukn (Threadpool Worker) 7 4 d5a 000000000130DA40 1021220 Preemptive 00007F6678106860:00007F6678106F20 0000000001306450 1 Ukn (Threadpool Worker)



我们关心的线程3418的16进制是d5a, 也就是最后一行, 它的DBG是7, 我们需要使用 setthread 7, 将其设置为  当前操作的线程


然后使用 clrstack 获取线程调用信息



> setthread 7 > clrstack OS Thread Id: 0xd5a (7) Child SP IP Call Site 00007F6715561558 00007f671a2bd4bd [InlinedCallFrame: 00007f6715561558] Interop+Sys.Write(System.Runtime.InteropServices.SafeHandle, Byte*, Int32) 00007F6715561558 00007f669f669a9e [InlinedCallFrame: 00007f6715561558] Interop+Sys.Write(System.Runtime.InteropServices.SafeHandle, Byte*, Int32) 00007F6715561540 00007F669F669A9E ILStubClass.IL_STUB_PInvoke 00007F67155615E0 00007F669F67333E System.ConsolePal.Write(Microsoft.Win32.SafeHandles.SafeFileHandle, Byte*, Int32, Boolean) 00007F67155616A0 00007F669F67360C System.ConsolePal.Write(Microsoft.Win32.SafeHandles.SafeFileHandle, Byte[], Int32, Int32, Boolean) [/_/src/System.Console/src/System/ConsolePal.Unix.cs @ 1236] 00007F67155616C0 00007F669F672B2A System.IO.StreamWriter.Flush(Boolean, Boolean) [/_/src/System.Private.CoreLib/shared/System/IO/StreamWriter.cs @ 261] 00007F6715561710 00007F669F6729F3 System.IO.StreamWriter.WriteLine(System.String) [/_/src/System.Private.CoreLib/shared/System/IO/StreamWriter.cs @ 474] 00007F6715561760 00007F669F6727D3 System.IO.TextWriter+SyncTextWriter.WriteLine(System.String) [/_/src/System.Private.CoreLib/shared/System/IO/TextWriter.cs @ 891] 00007F67155617A0 00007F669F672770 System.Console.WriteLine(System.String) [/_/src/System.Console/src/System/Console.cs @ 550] 00007F67155617C0 00007F669F663791 NetCoreDumpTest.Program.PrintNumber(System.String, Int32) [/home/zhouke/NetCoreDumpTest/Program.cs @ 18] 00007F6715561800 00007F669F6636D9 NetCoreDumpTest.Program+<>c.<Main>b__0_0() 00007F6715561820 00007F669F1872A1 System.Threading.Tasks.Task.InnerInvoke() [/_/src/System.Private.CoreLib/shared/System/Threading/Tasks/Task.cs @ 2466] 00007F6715561840 00007F669F18CBC2 System.Threading.Tasks.Task+<>c.<.cctor>b__274_0(System.Object) [/_/src/System.Private.CoreLib/shared/System/Threading/Tasks/Task.cs @ 2445] 00007F6715561850 00007F669F171AF2 System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(System.Threading.Thread, System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object) [/_/src/System.Private.CoreLib/shared/System/Threading/ExecutionContext.cs @ 289] 00007F6715561890 00007F669F187111 System.Threading.Tasks.Task.ExecuteWithThreadLocal(System.Threading.Tasks.Task ByRef, System.Threading.Thread) [/_/src/System.Private.CoreLib/shared/System/Threading/Tasks/Task.cs @ 2406] 00007F6715561910 00007F669F186F28 System.Threading.Tasks.Task.ExecuteEntryUnsafe(System.Threading.Thread) [/_/src/System.Private.CoreLib/shared/System/Threading/Tasks/Task.cs @ 2344] 00007F6715561930 00007F669F186EBB System.Threading.Tasks.Task.ExecuteFromThreadPool(System.Threading.Thread) 00007F6715561940 00007F669F17B754 System.Threading.ThreadPoolWorkQueue.Dispatch() [/_/src/System.Private.CoreLib/shared/System/Threading/ThreadPool.cs @ 663] 00007F67155619C0 00007F669F169A5B System.Threading._ThreadPoolWaitCallback.PerformWaitCallback() [/_/src/System.Private.CoreLib/src/System/Threading/ThreadPool.CoreCLR.cs @ 29] 00007F6715561D50 00007f6718a1ccaf [DebuggerU2MCatchHandlerFrame: 00007f6715561d50]





哗啦啦一大片, 有点Java调用堆栈的味道, 不过我们还是找到了我们的问题代码


NetCoreDumpTest.Program.PrintNumber(System.String, Int32)




有时候我们想知道传入的什么参数导致CPU占用高, 可以给clrstack加上参数 -a



> clrstack -a .............. 00007F0DD6FFC7C0 00007F0D6EEF3791 NetCoreDumpTest.Program.PrintNumber(System.String, Int32) [/home/zhouke/NetCoreDumpTest/Program.cs @ 18] PARAMETERS: message (0x00007F0DD6FFC7E8) = 0x00007f0d4800b8b0 startNumber (0x00007F0DD6FFC7E4) = 0x0000000000000005 LOCALS: 0x00007F0DD6FFC7E0 = 0x000000000014e42b 0x00007F0DD6FFC7DC = 0x0000000000000001 ...............



可以看到PARAMETERS里, startNumber作为值类型, 可以直接看到数值为5, 而message是引用类型, 指向0x00007f0d4800b8b0, 这时候需要用到 dumpobj 命令



> dumpobj 0x00007f0d4800b8b0 Name: System.String MethodTable: 00007f0d6ef70f90 EEClass: 00007f0d6eede1c0 Size: 32(0x20) bytes File: /home/zhouke/dotnet/shared/Microsoft.NETCore.App/3.0.0-preview6-27804-01/System.Private.CoreLib.dll String: Print Fields: MT Field Offset Type VT Attr Value Name 00007f0d6ef6a138 400022b 8 System.Int32 1 instance 5 _stringLength 00007f0d6ef66f38 400022c c System.Char 1 instance 50 _firstChar 00007f0d6ef70f90 400022d 108 System.String 0 static 00007f0d47fff360 Empty



好了, 可以看到它是一个字符串, 内容为 "Print"


假如message是一个复杂类型, 可以查看Fields下面的信息进一步查看


clrstack 还有一个实验性质的参数 -i, 协助查看各种变量信息, 需要用到lldb, 按照官方教程, 我暂时没有实验成功.




查看进程ID和线程ID, 更方便的方法是 htop(需要安装), 然后按 F4 进行过滤, 输入dotnet 即可



这张图是重新运行问题程序的结果, 进程ID和线程ID与前面不一样


第二行白色的是进程ID=1650, 第一行CPU占用高, 是问题线程ID=1658








End

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 151,511评论 1 330
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 64,495评论 1 273
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 101,595评论 0 225
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 42,558评论 0 190
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 50,715评论 3 270
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 39,672评论 1 192
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,112评论 2 291
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,837评论 0 181
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 33,417评论 0 228
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,928评论 2 232
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,316评论 1 242
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,773评论 2 234
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,253评论 3 220
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,827评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,440评论 0 180
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 34,523评论 2 249
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 34,583评论 2 249

推荐阅读更多精彩内容