【 某某提到: 】
: 一臺服務(wù)器裝有windows server 2008 r2，安裝16G內(nèi)存并設(shè)置16G虛擬內(nèi)存。最近在運行一個用C#編寫的大規(guī)模計算程序時發(fā)現(xiàn)，有很大一部分物理內(nèi)存被莫名其妙地消耗了。資源監(jiān)視器顯示該程序占用物理內(nèi)存不到5G，但是總的物理內(nèi)存消耗接近10G，可用物理內(nèi)存僅剩6G。隨著運?
: 除了這個程序之外沒有其它程序大量占用內(nèi)存。這個程序有大量磁盤IO操作，在運行中會不時地調(diào)用GC.Collect()以及時清理不用的內(nèi)存。這個實驗中用到的一系列程序的結(jié)構(gòu)基本相同，都會不時調(diào)用GC清理，但其它程序的內(nèi)存使用都正常，只有這個程序會出現(xiàn)占用內(nèi)存是實際使用的
: 請問為什么會出現(xiàn)這樣莫名其妙多占用內(nèi)存的情況呢？謝謝大家
這個既不是應(yīng)用本身的bug，也不是系統(tǒng)的memory leak。
當(dāng)前資源監(jiān)視器中關(guān)于系統(tǒng)物理內(nèi)存，有這么幾個統(tǒng)計項，可用、緩存、總數(shù)、已安裝；其中"緩存"這項，代表著已用于文件系統(tǒng)、網(wǎng)絡(luò)等等子系統(tǒng)的數(shù)據(jù)緩沖存儲的內(nèi)存容量，其中包含數(shù)量巨大的駐留在物理內(nèi)存中的數(shù)據(jù)頁面。而這樣的物理內(nèi)存消耗并沒有歸入任何一個進(jìn)程列表顯示的進(jìn)程所占用的物理內(nèi)存。這就是為什么下面公式，
進(jìn)程列表顯示的所有進(jìn)程所占用的物理內(nèi)存之和 + 可用物理內(nèi)存 < 物理內(nèi)存總數(shù)
，成立的原因所在。
導(dǎo)致這一現(xiàn)象的原因，從這個大規(guī)模計算程序的行為描述看，基本可以斷定是由于以下兩點，
1）應(yīng)用本身的大規(guī)模數(shù)據(jù)駐留物理內(nèi)存，導(dǎo)致parser.exe進(jìn)程龐大的working set；
2）大量頻繁的IO操作，引起大量的物理內(nèi)存為系統(tǒng)緩存所占用；
對于1),必須注意，GC.Collect()只是設(shè)置使能垃圾收集的標(biāo)志位，并沒有立即啟動垃圾收集過程，這個過程的實際啟動時刻由CLR來動態(tài)決議；
所以如果要獲得即時的托管內(nèi)存的釋放，并進(jìn)一步釋放物理內(nèi)存以減小當(dāng)前進(jìn)程的working set，可以使用AppDomain這個.net下可以用來資源劃分、獲取和釋放的，在概念上近似于輕量級進(jìn)程的編程語義；在AppDomain中獲取的各種資源，包括托管內(nèi)存、加載其中的各個assembly以及CCW等，在此AppDomain被釋放時都被相應(yīng)的及時釋放（或者引用計數(shù)遞減）。
對于2），重新觀察先前的設(shè)計實現(xiàn)和模型，考慮是否能把一些分散的IO操作合并起來進(jìn)行，比如,
for(long i=0; i < Count; ++i)
{
...
objIO.Operation(Data[i], 1);
...
}
修改為
for(long i=0; i < Count; ++i)
{
...
...
}
objIO.Operation(Data, Count);
這樣對于提高應(yīng)用的IO效率以及提升系統(tǒng)緩存利用率應(yīng)當(dāng)會有幫助。
對于2），系統(tǒng)緩存隨著這個大規(guī)模計算應(yīng)用的進(jìn)行而逐步增大，并最后導(dǎo)致整個系統(tǒng)無法獲取的物理內(nèi)存而無法繼續(xù)運行的現(xiàn)象，估計即使采用了在上文提出的，在應(yīng)用程序代碼中盡可能合并IO操作，減少IO次數(shù)的方法，也不會改善系統(tǒng)緩存占用物理內(nèi)存數(shù)量過大的問題。這個問題本質(zhì)上是Windows操作系統(tǒng)本身從NT時代到現(xiàn)在，一直存在的問題，主要是圍繞著Windows kernel中的Cache mananger以及memory manager核心態(tài)組件的實現(xiàn)機制而產(chǎn)生的。
根據(jù)目前的Cc(對Cache manager的簡稱，在WindowsResourceKernel開源項目中，Cache manager相關(guān)模塊的函數(shù)都以Cc作為前綴，比如CcCopyRead，CcFlushCache等，Memory manager也同樣簡稱Mm)的實現(xiàn)機制，所有對文件系統(tǒng)的訪問，包括本地和網(wǎng)絡(luò)，都會首先由Cc對相關(guān)頁面作緩存映射，隨著頻繁的IO的操作，被Cc緩存的頁面也迅速遞增，而被緩存頁面占用多少物理內(nèi)存，這是由Windows kernel中的Memory manager決定。目前在64位平臺上，系統(tǒng)緩存最高可達(dá)1TB，所以這個應(yīng)用進(jìn)程的運行中出現(xiàn)分配8G的緩存是完全可能的，但同時問題也隨之而來，那就是系統(tǒng)緩存占用了過多的物理內(nèi)存，導(dǎo)致其他進(jìn)程以及內(nèi)核本身無法申請足夠的物理內(nèi)存，最后致使系統(tǒng)“僵死”；
對于這個問題，微軟提供了“Microsoft Windows Dynamic Cache Service”工具來提供對系統(tǒng)緩存的工作集working set容量（也就是駐留物理內(nèi)存的大小）的控制，這個工具主要是對SetSystemFileCacheSize的封裝，可以設(shè)置系統(tǒng)緩存容量的上下限。
但這只是一種臨時的解決方案，因為應(yīng)用雖然可以通過上面這個Dynamic Cache Service來設(shè)置和限制系統(tǒng)緩存容量的大小，但是如何確定緩存容量大小的非常困難，如果過小，所有IO性能大受影響，整個Cc如同虛設(shè)；如果過大(等價于不受限)，那么系統(tǒng)緩存占用過多物理內(nèi)存導(dǎo)致系統(tǒng)僵死的現(xiàn)象就會重現(xiàn)。
所以從根本上看，這個問題應(yīng)由包括Cc和Mm在內(nèi)的整個Windows kernel作出完整一致的調(diào)整，但從目前的實現(xiàn)看要完成整個方案改動很大，據(jù)稱這個改進(jìn)可能會考慮包含在Win7中發(fā)布。
Microsoft Windows Dynamic Cache Service下載,
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=e24ade0a-5efe-43c8-b9c3-5d0ecb2f39af&displaylang=en
Microsoft Windows Dynamic Cache Service相關(guān)的介紹，
http://blogs.msdn.com/b/ntdebugging/archive/2009/02/06/microsoft-windows-dynamic-cache-service.aspx