Al *_*l W 3 asp.net iis windbg debugdiag
我们的应用程序池每天循环多次。我很确定这是因为它达到了内存限制。我也很确定它不应该达到 ~3GB 的内存限制。我尝试使用 WinDbg 来分析内存转储,但收效甚微。我可能稍后再试。然而,使用 DebugDiag 为我提供了一些很好的数据可视化效果,并且已经导致了一些减少回收次数的变化。一份让我有点困惑和担心的报告是 HttpContext 报告。它显示了一些这样的输出:
HttpContext Timeout Completed RunningSince ThreadId ReturnCode Verb RequestPath+QueryString
0x02374c94 110 Sec No 995 Sec --- 302 GET /Loans/Details/529146/517006
0x02472a44 110 Sec No 993 Sec --- 200 GET /Login ReturnUrl=%2fLoans%2fDetails%2f529146%2f517006
0x024d2f94 110 Sec No 979 Sec --- 302 POST /Loans/UpdateDealer
0x025773c0 110 Sec No 951 Sec --- 302 GET /Applicants
0x025d6bb4 110 Sec No 951 Sec --- 200 GET /Login ReturnUrl=%2fApplicants
0x025f5adc 110 Sec No 935 Sec --- 302 GET /Applicants/Details/537358
0x02654708 110 Sec No 935 Sec --- 200 GET /Login ReturnUrl=%2fApplicants%2fDetails%2f537358
0x026b1bb4 110 Sec No 926 Sec --- 200 POST /Loan/InsertLoanChecklistItem
0x027710dc 110 Sec No 914 Sec --- 200 GET /Applicants
0x02779320 110 Sec No 915 Sec --- 302 POST /Login ReturnUrl=%2fApplicants
0x02797448 110 Sec No 914 Sec --- 200 GET /Loans/Details/523729/526198
0x02867070 110 Sec No 911 Sec --- 200 POST /Loans/UpdateAmount
Run Code Online (Sandbox Code Playgroud)
当然,报告中还有更多行。我是否真的有已运行 995 秒(约 15 分钟)但仍未完成的请求?他们只是挂在那里吗?他们在等待其他事情完成吗?我不确定我什至能相信它,更不用说开始诊断它了。其他人能否让我深入了解如何解释这些数据?
经过长时间的研究,我得到了解决方案,而不是确切的解决方案,但它可以提供帮助。
long running since 列指示从其第一个请求开始的时间。这并不意味着请求时间是为任何用户完成任何单个请求。所以,这里没有什么可担心的这么高的数字。
编辑:http : //blogs.msdn.com/b/yunjin/archive/2005/08/25/456355.aspx
http://blogs.msdn.com/b/yunjin/archive/2005/08/29/457150.aspx
http://social.msdn.microsoft.com/Forums/en/vsdebug/thread/17f783cd-d5af-4146-ab46-be80e62da750
对于内存泄漏,我建议使用 WinDbg。WinDbg 参考:
http://blogs.msdn.com/b/alejacma/archive/2009/06/30/sos-cheat-sheet-net-2-0-3-0-3-5.aspx
http://geekswithblogs.net/.NETonMyMind/archive/2006/03/14/72262.aspx
| 归档时间: |
|
| 查看次数: |
1411 次 |
| 最近记录: |