2012-03-12 46 views
23

我對IIS 7.0在它自己的應用程序池中的網站的應用程序。該應用程序是一個ASP.NET MVC 3網站。高內存使用IIS 7

我已經注意到了相應的w3wp IIS工作者服務這個應用程序的內存使用率相當高(800 MB,與一些波動)。

我試圖診斷問題,並嘗試以下操作:

我的網站在IIS級別禁用輸出頁面緩存,然後循環應用程序池。這會導致w3wp進程重新啓動。這個過程的內存使用率然後緩慢爬升到800 MB左右,這需要大約30秒。目前沒有處理頁面請求。當我從IIS重新啓動網站時,進程的內存大小不會改變。

我試圖運行從2010年的VS應用程序的調試副本,所以內存使用沒有問題。

一些想法,我有/問題是:

是這個問題關係到網站的代碼? - 鑑於任何頁面請求之前的內存火箭已經發送/處理,我會認爲這不是代碼問題?

建在MVC應用程序沒有處理緩存的寫入它。

該網站使用實時顯示數據,它定期使用ajax請求,並且通常長時間處於「打開」狀態。

爲什麼內存使用火箭的應用程序經過長達被回收並沒有用戶的請求被髮送?這是因爲它將舊的緩存信息從磁盤加載到它的內存中?

應用程序不會崩潰,我只是擔心內存使用,它不是一個大的網站......與得到這個問題的底部

任何想法/幫助,將不勝感激。

回答

14

我只看我的服務器和我的池使用900-1000MB虛擬大小內存和380MB工作集。幾年來,我的網站運行平穩,並且我已經從各個方面進行檢查。我的池永不回收,服務器運行,直到下一次更新持續40%穩定的可用物理內存。

如果你的內存不是繼續增長,那麼這個內存就是代碼加上你在應用程序中設置爲靜態,常量,字符串和可能的緩存的數據。

您可以使用process explorer來查看工作內存和虛擬內存大小。

您也可以考慮針對您的代碼運行配置文件,以查看是否有任何「內存泄漏」或其他問題。從谷歌搜索一個:https://www.google.com/search?hl=en&q=asp.net+memory+profiler

+1

順便說一句 - 您將處於40%穩定狀態,因爲默認情況下,IIS中的processModel僅限於使用60%的可用內存。你可以通過processModel memoryLimit設置來改變它。 – ProVega 2014-09-19 20:51:53

+0

@ProVega其實在IIS旁邊,有ms sql server和ms backup程序。 ms備份程序可以吃掉所有可用內存,使系統變慢。然後,MS SQL服務器也可以吃掉大量的內存緩存,所以我設置了內存最大限制。所以我最終有一些空閒的內存,因爲我已經檢查過了。 – Aristos 2014-09-20 05:57:42

+0

也在應用程序池的高級設置彈出窗口中,將啓用32位應用程序設置爲true還可以減少內存使用量。看到這篇文章的信息http://www.sitefinity.com/developer-network/forums/bugs-issues-/app-pool-memory-drastically-different-from-32-64-bit – 2015-12-05 07:51:08

17

如果您可以負擔得起使用調試器,最好的辦法是安裝Windows Debugging Tools並使用類似WinDbg和SOS.dll的內容來找出內存中的內容。

一旦你安裝的工具,那麼你可以:

  1. 啓動WINDBG.EXE運行升高(如管理員)
  2. 使用「文件 - >附加到進程」,然後選擇w3wp.exe的對你正試圖弄清楚的應用程序。如果您有很多可以使用任務管理器並添加命令行列來查看PID或使用IIS管理器 - >工作進程找出它,然後在WinDBG中選擇該進程。
  3. 運行:
  4. .loadby SOS CLR
  5. dumpheap -stat

在這一點上,你應該能夠看到最消耗內存排序的所有類型,所以你可以用那些在開始底端。 (我會建議排除Strings和Object,因爲這些通常是副作用而不是原因)。 使用「!dumpheap -type type-here」查找實例,並使用!gcroot爲那些弄清楚它們爲什麼在內存中,可能是由於靜態字段,泄漏的事件處理程序,WCF通道未處理或事物這是常見的來源。

3

它可能不適用於此,但我認爲我會把它扔在一個很好的措施。最近我遇到了一個問題,那就是當我的記憶真的可以清理80%的時候,我的記憶就會正確無誤地出現。問題:它認爲它比實際上大約多出了2次,因此GC非常懶惰。 (這是由於虛擬機器件的bug - 窗口報告8 Gig,但實際上只有6.4)。查看博客。 http://www.worthalook.net/2014/01/give-back-memory/

0

可能有幫助的東西:如果您「重寫」(打開/保存)web.config,那麼您的應用程序將重置,您應該監視該點的內存使用情況。如果在使用過程中不斷增長,這可能意味着內存泄漏或瘋狂的緩存。您可能能夠確定您網站上的哪些操作會導致內存增加。在很長一段時間內,應用程序的內存使用應該穩定。