Question

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

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

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*)

我能理解一个，但为什么这么多。它是特定于我们正在使用的业务流程建模引擎还是典型的东西？我猜它正在接受其他客户可以使用的线程，这就是用户报告减速的原因。我之前问过的那些线程是完成端口线程吗？我可以做更多的诊断，或者我发现我们的代码是原因吗？

Answer 1

从输出的外观来看，大部分内存都不在.net堆上（~650只有35 MB）所以如果你正在查看.net堆，我认为你看错了地方。如果您使用某些本机组件进行文件传输或类似操作，则内存可能位于程序集或本机内存中。您可能希望使用Debug Diag来监视它。

很难说你是否在没有看到增长模式的情况下泄漏动态组件所以我建议你看看perfmon和#current组件，看看它是否会随着时间的推移而不断增长，如果确实如此将不得不通过查看动态组件的内容来进一步调查！dda

帮我分析转储文件

1 个答案: