拿品牌做网站算侵权吗,做网站要了解的事情,php+mysql网站开发,做网站文字编辑累吗一#xff1a;背景
1. 讲故事
前些天有位朋友找到我#xff0c;说他们的程序内存会偶发性暴涨#xff0c;自己分析了下是非托管内存问题#xff0c;让我帮忙看下怎么回事#xff1f;哈哈#xff0c;看到这个dump我还是非常有兴趣的#xff0c;居然还有这种游戏币自助机…一背景
1. 讲故事
前些天有位朋友找到我说他们的程序内存会偶发性暴涨自己分析了下是非托管内存问题让我帮忙看下怎么回事哈哈看到这个dump我还是非常有兴趣的居然还有这种游戏币自助机类型的程序下次去大玩家看看他们出币的机器后端是不是C#写的由于dump是linux上的程序刚好windbg可以全平台分析太爽了直接用windbg开干吧。
二WinDbg 分析
1. 到底是哪里的泄漏
在 windows 平台上相信有很多朋友都知道用 !address -summary 命令看但这是专属于windows平台的命令在分析linux上的dump不好使参考如下输出 0:000 !address -summary--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
unknown 1685 7ffcd6725c00 ( 127.988 TB) 100.00% 100.00%
Image 7102 00b524400 ( 181.142 MB) 0.00% 0.00%--- Type Summary (for busy) ------ RgnCount ----------- Total Size -------- %ofBusy %ofTotal2248 7ffc02549000 ( 127.984 TB) 100.00%
MEM_PRIVATE 6539 0df701000 ( 3.491 GB) 0.00% 0.00%--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal2248 7ffc02549000 ( 127.984 TB) 100.00% 100.00%
MEM_COMMIT 6539 0df701000 ( 3.491 GB) 0.00% 0.00%--- Protect Summary (for commit) - RgnCount ----------- Total Size -------- %ofBusy %ofTotal
PAGE_READWRITE 2099 0dd75e000 ( 3.460 GB) 0.00% 0.00%
PAGE_EXECUTE_WRITECOPY 33 000d4c000 ( 13.297 MB) 0.00% 0.00%
PAGE_READONLY 2736 000b01000 ( 11.004 MB) 0.00% 0.00%
PAGE_EXECUTE_READ 1671 000756000 ( 7.336 MB) 0.00% 0.00%--- Largest Region by Usage ----------- Base Address -------- Region Size ----------
unknown 000000000 55cb2dc3b000 ( 85.794 TB)
Image 7f719dbdd000 001b16000 ( 27.086 MB)
卦中的内存段分类用处不大也没有多大的参考价值那怎么办呢其实 coreclr 团队也考虑到了这个情况它提供了一个 maddress 命令来实现跨平台的 !address更改后输出如下 0:000 !sos maddress
Enumerating and tagging the entire address space and caching the result...
Subsequent runs of this command should be faster.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | Memory Kind | StartAddr | EndAddr-1 | Size | Type | State | Protect | Image | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | Stack | 7f6e356ec000 | 7f6e35eec000 | 8.00mb | MEM_PRIVATE | MEM_COMMIT | PAGE_READWRITE | | | Stack | 7f6e35eed000 | 7f6e366ed000 | 8.00mb | MEM_PRIVATE | MEM_COMMIT | PAGE_READWRITE | | | Stack | 7f6e366ee000 | 7f6e36eee000 | 8.00mb | MEM_PRIVATE | MEM_COMMIT | PAGE_READWRITE | | | Stack | 7f6e36eef000 | 7f6e376ef000 | 8.00mb | MEM_PRIVATE | MEM_COMMIT | PAGE_READWRITE | | ...------------------------------------------------------------------------- | Memory Type | Count | Size | Size (bytes) | ------------------------------------------------------------------------- | Stack | 423 | 3.29gb | 3,528,859,648 | | Image | 7,102 | 181.14mb | 189,940,736 | | PAGE_READWRITE | 206 | 89.18mb | 93,511,680 | | GCHeap | 3 | 37.75mb | 39,587,840 | | HighFrequencyHeap | 395 | 24.66mb | 25,858,048 | | LowFrequencyHeap | 316 | 22.20mb | 23,277,568 | | LoaderCodeHeap | 13 | 17.00mb | 17,825,792 | | ResolveHeap | 2 | 732.00kb | 749,568 | | HostCodeHeap | 8 | 668.00kb | 684,032 | | DispatchHeap | 1 | 196.00kb | 200,704 | | PAGE_EXECUTE_WRITECOPY | 6 | 184.00kb | 188,416 | | CacheEntryHeap | 3 | 164.00kb | 167,936 | | IndirectionCellHeap | 3 | 152.00kb | 155,648 | | LookupHeap | 3 | 144.00kb | 147,456 | | StubHeap | 2 | 76.00kb | 77,824 | | PAGE_EXECUTE_READ | 1 | 4.00kb | 4,096 | ------------------------------------------------------------------------- | [TOTAL] | 8,487 | 3.65gb | 3,921,236,992 | -------------------------------------------------------------------------
从卦中可以看到当前程序总计 3.65G 内存占用基本上都被线程栈给吃掉了更让人意想不到的是这个线程栈居然占用 8M 的内存空间这个着实有点大了而且 linux 不像 windows 有一个 reserved 的概念这里的 8M 是实实在在的预占可以观察这 8M 的内存地址即可都是初始化的 0, 这就说不过去了。 0:000 dp 7f6e356ec000 7f6e35eec000
00007f6e356ec000 0000000000000000 0000000000000000
...
00007f6e35eebfc0 0000000000000000 0000000000000000
00007f6e35eebfd0 0000000000000000 0000000000000000
00007f6e35eebfe0 0000000000000000 0000000000000000
00007f6e35eebff0 0000000000000000 0000000000000000
2. 如何修改栈空间大小
一般来说不同的操作系统发行版有不同的默认栈空间配置可以先到内存搜一下当前是哪一个发行版做法就是搜索操作系统名称主要关键字。 0:000 s-a 0 L?0xffffffffffffffff centos
...
000055cb2ecf08c8 63 65 6e 74 6f 73 2e 37-2d 78 36 34 00 00 00 00 centos.7-x64....
...
从卦中可以看到当前操作系统是 centos7-x64在 windows 平台上修改栈空间大小可以修改 PE 头在 linux 上有两种做法。
修改 ulimit -s 参数 rootubuntu:/data# ulimit -s
8192
rootubuntu:/data# ulimit -s 2048
rootubuntu:/data# ulimit -s
2048
修改 DOTNET_DefaultStackSize 环境变量 DOTNET_DefaultStackSize180000
更多可以参考文章 https://www.alexander-koepke.de/post/2023-10-18-til-dotnet-stack-size/
上面是解决问题的第一个方向接下来我们说另一个方向为什么会产生总计 423 个线程呢
3. 为什么会有那么多线程
要找到这个答案需要去看每一个线程此时都在干嘛这个可以使用 windbg 专属命令。 0:000 ~*e !clrstack
...
OS Thread Id: 0x4e (24)Child SP IP Call Site
00007F70B20FC4B0 00007f71a4131ad8 [InlinedCallFrame: 00007f70b20fc4b0] /app/Confluent.Kafka.dll!Unknown
00007F70B20FC4B0 00007f7130299970 [InlinedCallFrame: 00007f70b20fc4b0] /app/Confluent.Kafka.dll!Unknown
00007F70B20FC4A0 00007f7130299970 ILStubClass.IL_STUB_PInvoke(IntPtr, IntPtr)
00007F70B20FC530 00007f7130309fab /app/Confluent.Kafka.dll!Unknown
00007F70B20FC880 00007f7131c5a75d /app/Confluent.Kafka.dll!Unknown
00007F70B20FC8A0 00007f7130303ebe /app/DotNetCore.CAP.Kafka.dll!Unknown
00007F70B20FC980 00007f71302f4854 /app/DotNetCore.CAP.dll!Unknown
00007F70B20FCA50 00007f7129b187f4 System.Threading.Tasks.Task.InnerInvoke() [/_/src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs 2387]
00007F70B20FCA70 00007f7129b1d316 System.Threading.Tasks.Taskc..cctorb__272_0(System.Object) [/_/src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs 2375]
00007F70B20FCA80 00007f7129b03d6b System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object) [/_/src/libraries/System.Private.CoreLib/src/System/Threading/ExecutionContext.cs 183]
00007F70B20FCAD0 00007f7129b18524 System.Threading.Tasks.Task.ExecuteWithThreadLocal(System.Threading.Tasks.Task ByRef, System.Threading.Thread) [/_/src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs 2333]
00007F70B20FCB50 00007f7129b18418 System.Threading.Tasks.Task.ExecuteEntryUnsafe(System.Threading.Thread) [/_/src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs 2271]
00007F70B20FCB70 00007f7129b21a67 System.Threading.Tasks.ThreadPoolTaskSchedulerc..cctorb__10_0(System.Object) [/_/src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/ThreadPoolTaskScheduler.cs 35]
00007F70B20FCB80 00007f7129af88c2 System.Threading.Thread.StartCallback() [/_/src/coreclr/System.Private.CoreLib/src/System/Threading/Thread.CoreCLR.cs 105]
00007F70B20FCCF0 00007f71a37ab9c7 [DebuggerU2MCatchHandlerFrame: 00007f70b20fccf0]
...
从卦中数据看有很多的 Unknown说明dump取得不好可能不是用正规的 dotnet-dump 或者 procdump但不管怎么说还是可以看到大量的和 Kafka 有关的链接库并且从 InnerInvoke 这个执行 m_action 来看应该是有大量线程卡在 Kafka 中的某个函数上。
有了这些知识最后给到朋友的建议如下
修改 DOTNET_DefaultStackSize 参数
可以仿照 windows 上的 .netcore 默认 1.5M 的栈空间设置因为8M真的太大了扛不住也和 Linux 的低内存使用不符。
观察 Kafka 的相关逻辑
毕竟有大量线程在 Kafka 的等待上个人觉得可能是订阅线程太多或者什么业务执行时间长导致的线程饥饿尽量把线程压下去。
三总结
Linux 上的 .NET 调试生态在日渐丰富这是一件让人很兴奋的事情最后再给 WinDbg 点个赞它不仅可以全平台dump分析还可以实时调试 Linux 进程现如今的WinDbg真的是神一般的存在。
