Windbg 帮助我分析转储文件

客户几乎每天都在同一时间报告问题。此应用程序正在2个节点上运行。这是Metastorm BPM平台，它正在调用我们的代码

在一些转储中，我注意到运行的线程非常长（约50分钟），但并非所有线程都如此。管理员还告诉我，就在用户报告问题之前，内存使用率上升了。然后一切都会减慢到无法工作的程度，管理员必须在两个节点上重新启动平台。我的第一个想法是死锁（长时间运行的线程），但没有设法证实这一点！syncblk没有返回任何内容。然后我看了一下内存使用情况。我注意到很多动态组件，所以认为可能组件泄漏。但看起来不是这样。我收到了从那个天起的转储，那个时一切正常，动态程序集的数量相似。所以我想可能是内存泄漏。但也无法证实！dumpheap-stat显示内存使用量在增长，但我没有发现任何有趣的东西！根。但有一件事我不知道是什么。线程池完成端口。有很多。那么，也许某事物正在等待某事物？这里是我可以给你的数据，到目前为止，将适合在这个职位。你能提出一些有助于诊断这种情况的建议吗

Users not reporting problems:
                    Node1                       Node2
Size of dump:       638MB                       646MB
DynamicAssemblies   259                         265
GC Heaps:           37MB                        35MB                    
Loader Heaps:       11MB                        11MB

Node1:
Number of Timers: 12
CPU utilization 2%
Worker Thread: Total: 5 Running: 0 Idle: 5 MaxLimit: 2000 MinLimit: 200
Completion Port Thread:Total: 2 Free: 2 MaxFree: 16 CurrentLimit: 4 MaxLimit: 1000 MinLimit: 8

!dumpheap -stat (biggest)
0x793041d0   32,664    2,563,292 System.Object[]
0x79332b9c   23,072    3,485,624 System.Int32[]
0x79330a00   46,823    3,530,664 System.String
0x79333470   22,549    4,049,536 System.Byte[]

Node2:
Number of Timers: 12
CPU utilization 0%
Worker Thread: Total: 7 Running: 0 Idle: 7 MaxLimit: 2000 MinLimit: 200
Completion Port Thread:Total: 3 Free: 1 MaxFree: 16 CurrentLimit: 5 MaxLimit: 1000 MinLimit: 8

!dumpheap -stat
0x793041d0   30,678    2,537,272 System.Object[]
0x79332b9c   21,589    3,298,488 System.Int32[]
0x79333470   21,825    3,680,000 System.Byte[]
0x79330a00   46,938    5,446,576 System.String
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Users start to report problems:
                    Node1                      Node2
Size of dump:       662MB                       655MB
DynamicAssemblies   236                         235
GC Heaps:           159MB                       113MB                   
Loader Heaps:       10MB                        10MB

Node1:
Work Request in Queue: 0
Number of Timers: 14
CPU utilization 20%
Worker Thread: Total: 7 Running: 0 Idle: 7 MaxLimit: 2000 MinLimit: 200
Completion Port Thread:Total: 48 Free: 1 MaxFree: 16 CurrentLimit: 49 MaxLimit: 1000 MinLimit: 8

!dumpheap -stat
0x7932a208   88,974    3,914,856 System.Threading.ReaderWriterLock
0x79333054   71,397    3,998,232 System.Collections.Hashtable
0x24f70350  319,053    5,104,848 Our.Class
0x79332b9c   53,190    6,821,588 System.Int32[]
0x79333470   52,693    6,883,120 System.Byte[]
0x79333150   72,900   11,081,328 System.Collections.Hashtable+bucket[]
0x793041d0  247,011   26,229,980 System.Object[]
0x79330a00  644,807   34,144,396 System.String

Node2:
Work Request in Queue: 1
Number of Timers: 17
CPU utilization 17%
Worker Thread: Total: 6 Running: 0 Idle: 6 MaxLimit: 2000 MinLimit: 200
Completion Port Thread:Total: 48 Free: 2 MaxFree: 16 CurrentLimit: 49 MaxLimit: 1000 MinLimit: 8

!dumpheap -stat
0x7932a208   76,425    3,362,700 System.Threading.ReaderWriterLock
0x79332b9c   42,417    5,695,492 System.Int32[]
0x79333150   41,172    6,451,368 System.Collections.Hashtable+bucket[]
0x79333470   44,052    6,792,004 System.Byte[]
0x793041d0  175,973   18,573,780 System.Object[]
0x79330a00  397,361   21,489,204 System.String

编辑： 我下载了debugdiag并让它分析我的转储。以下是部分输出：

The following threads in process_name name_of_dump.dmp are making a COM call to thread 193 within the same process which in turn is waiting on data to be returned from another server via WinSock.

 The call to WinSock originated from 0x0107b03b and is destined for port xxxx at IP address xxx.xxx.xxx.xxx


( 18 76 172 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 210 211 212 213 214 215 216 217 218 224 225 226 227 228 229 231 232 233 236 239 )

14,79% of threads blocked

建议是：

Several threads making calls to the same STA thread can cause a performance bottleneck due to serialization. Server side COM servers are recommended to be thread aware and follow MTA guidelines when multiple threads are sharing the same object instance.

我使用windbg检查了线程193的功能。它正在调用我们的代码。我们的代码正在调用某个Metastorm引擎代码，它挂起在某个远程处理调用上。但是失控显示它被悬挂了8秒钟。没那么久。所以我检查了那些等待的线程。除螺纹18外，所有螺纹均为：

System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32, UInt32, System.Threading.NativeOverlapped*)
System.Threading.\u IOCompletionCallback.PerformIOCompletionCallback（UInt32，UInt32，System.Threading.NativeOverlapped*）
。它是特定于我们正在使用的业务流程建模引擎的，还是典型的？我猜它占用了其他客户机可以使用的线程，这就是为什么用户报告速度放缓的原因。这些线程是我以前问过的完成端口线程吗？我可以做更多的事情来诊断吗？或者我发现我们的代码是原因吗？
从输出的外观来看，大部分内存不在.net堆上（650个内存中只有35 MB），因此如果您查看的是.net堆，我想您找错地方了。如果您正在使用某些本机组件进行文件传输或类似操作，则内存可能位于程序集或本机内存中。您可能希望使用Debug Diag来监视它

如果不查看增长模式就很难说您是否泄漏了动态程序集，因此我建议您查看perfmon和#当前程序集，看看它是否会随着时间的推移而不断增长，如果是这样，那么您必须通过查看动态程序集是如何使用的来进一步调查它！多谢苔丝。我不知道DebugDiag工具。你能看看我用它发现了什么吗？你可以去苔丝的博客上学习。最快的方法是通过打开一个支持案例来咨询Microsoft支持专家。我知道我从Tess的博客中学到了什么。事实上，我让她到这里来：）