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