每個連接的MVC 4 IIS內存泄漏

Question

我設置了一個AsyncController來執行長輪詢操作。 一切正常，但是同事發現服務器上的內存泄漏似乎隨着每個新連接的增加而增加。

我已經創建了一個小應用程序來向該頁面請求數千次，並且正在監視IIS進程的內存使用情況。 每個連接都會增加內存使用量，但是在客戶端斷開連接后，連接不會一直下​​降。

經過進一步的調查，我發現即使將AsyncController替換為不執行任何操作的標准Controller仍然會發生這種情況：

public class WaitController : Controller
{
    public JsonResult Member(string oauth_token, int service_id, bool busy = false)
    {
        return Json(new
        {
            ready = false,
        }, JsonRequestBehavior.AllowGet);
    }
}

盡管這樣做沒有那么多的內存使用量，但是行為似乎是完全相同的。

我已經運行了一個內存探查器，以顯示10,000個連接之間的差異，那里幾乎沒有任何連接。 大多數內存由System.Web.Caching或System.Runtime.Caching的ExpiresEntry[]實例ExpiresEntry[] ，但是與我在IIS輔助進程中獲得的內存增加相比，這些內存總計ExpiresEntry[] 。

我的問題是 ，IIS是按設計進行的嗎？ 也許這已經分配給了連接線程，以防以后需要它們時懸掛它們？ 這是IIS，ASP.NET或MVC 4的錯誤嗎？

我決定為此使用MVC 4的WebAPI功能，因為我們希望它具有靈活性，可維護性，面向未來並且可以通過AJAX訪問。 從開發的角度來看，這似乎也很有意義，因為我們也在MVC 4中建立了該網站。

但是，現在一位同事提出這是系統體系結構的關鍵問題，因為我們（將來）將需要連接數千個客戶端。 他建議我們改用WCF。 那么，獎金問題-使用WCF是否可以解決這些問題？

Answer 1

MS現場工程師撰寫了一篇有關該主題的精彩文章 。 可能會有所幫助。

Answer 2

經過更多的試驗和測試，很遺憾，我發現這是無法避免的。 這似乎是設計使然，或者是IIS的一個根深蒂固的問題。

我更改了方法以使用較低級別的選項：實現IHttpAsyncHandler以執行相同的操作。 我為MVC使用了自定義HttpHandler路由，以允許我使用與以前完全相同的URL。 問題仍然存在，但規模較小。

然后，我嘗試了一個完全空白的IHttpHandler ， IHttpHandler返回{ ready: false } （就像我的代碼在超時時一樣）。 HttpHandler中沒有包含其他代碼，但是仍然會出現相同的問題。

接下來，我嘗試了一個完全空白的WCF服務，該服務還返回了{ ready: false } 。 同樣的問題，但是這次的規模更小。

如鏈接@rusev的答案所示：

內存碎片和其他自然退化是無法避免的，回收可以確保定期清理應用程序。

這可能是問題的原因。 我可以想象，由於使用MVC控制器時會有更多開銷，因此碎片化發生得更快。 使用較低級別的方法（例如HttpHandler或WCF服務）將減少每個連接的內存，因此減少碎片。