2012-11-16 59 views
3

我們的應用程序池一天可以回收數次。我很確定這是因爲它達到了內存限制。我也很確定它不應該達到〜3GB的內存限制。我嘗試使用WinDbg來分析內存轉儲,但收效甚微。我可能會在稍後再試。然而,使用DebugDiag給了我一些很好的數據可視化,並且已經導致了一些減少了回收次數的改變。一份讓我感到困惑和擔憂的報告是HttpContext報告。它顯示了一些這樣的輸出:DebugDiag顯示長時間運行自從

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 

當然,報告中有很多更多的行。我是否真的有運行995秒(〜15分鐘)的請求,但仍未完成?他們只是掛在那裏?他們是否在等待其他事情完成?我不確定我能相信它,更不用說開始診斷了。其他人能否告訴我如何解釋這些數據?

回答

3

經過長時間的研究,我得到了解決方案,而不是確切的解決方案,但它可以提供幫助。

自列以來的長時間運行表明從第一次請求開始的時間。 這並不意味着請求時間是爲任何用戶完成任何單個請求。 所以,這裏沒什麼好擔心的。

編輯: 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

+0

感謝您尋找到這一點。你有沒有在研究中發現的任何參考資料,我可以看一看? –