不知道從什么時候開始,網(wǎng)上開始流傳一種說法,WS2008系統(tǒng)自帶緩存有Bug,然后可能導(dǎo)致服務(wù)器內(nèi)存耗盡而死機!然后網(wǎng)上就出了一些工具解決這些問題!但事實上我一直沒能從微軟官方資料獲得相關(guān)說明,自己也沒遇到過這種現(xiàn)象,于是一直耿耿于懷……
注:大家可能經(jīng)?吹絎S2008、WS2012的寫法,WS=Windows Server的首字母簡寫,本站搜索文章推薦簡寫方式。
而今天在翻閱云更新產(chǎn)品歷史更新時,發(fā)現(xiàn)從V2015.4.15.830版本已經(jīng)會自動修改2008系統(tǒng)自帶緩存大小,于是勾起了研究的興趣。功夫不負有心人,終于找到微軟資料,并已證實2008系統(tǒng)確實存在該問題,但在Windows 7和Windows Server 2008r2版本中已經(jīng)得到更新,“可以解決已經(jīng)發(fā)現(xiàn)的問題”。
微軟資料中對WS2008系統(tǒng)緩存耗盡導(dǎo)致服務(wù)器死機的原因說明:
在 Microsoft Windows 操作系統(tǒng)中的內(nèi)存管理使用基于請求的算法。如果任何進程請求,并使用大量內(nèi)存,進程的工作集 (在物理內(nèi)存中的內(nèi)存頁面數(shù)) 都會增大。如果這些請求持續(xù)且未加抑制,進程的工作集將會增長至占用所有的物理內(nèi)存。在此情況下,其他所有進程的工作集調(diào)出到硬盤。這種行為降低了應(yīng)用程序和服務(wù)的性能,因為內(nèi)存頁是連續(xù)寫入硬盤和從硬盤讀取的。
這種行為同樣適用于系統(tǒng)文件緩存的工作集。如果這些請求是連續(xù)的且不受控制的,則該進程的工作集將繼續(xù)增長,直到消耗盡所有物理內(nèi)存。在這種情況下,所有其他進程的工作集分頁到硬盤,被占用的物理內(nèi)存量不可用于其他進程。
在 32 位 Windows 操作系統(tǒng)版本早于 Windows Vista,系統(tǒng)文件緩存的工作集是有理論內(nèi)存限制為小于 1 千兆字節(jié) (GB)。
在 32 位版本的 Windows Vista 操作系統(tǒng),動態(tài)分配核心資源。
在 64 位版本的 Windows 操作系統(tǒng),虛擬地址范圍通常通常超過了物理大小。
WS2008系統(tǒng)緩存耗盡導(dǎo)致服務(wù)器死機的解決方法:
若要變通解決此問題,請使用GetSystemFileCacheSize API 函數(shù)和SetSystemFileCacheSize API 函數(shù)來設(shè)置系統(tǒng)文件緩存的工作集的大小最大值或最小值。
Microsoft Windows 動態(tài)緩存服務(wù)是演示如何使用這些 Api 來將這一問題的影響降至最低的一種策略的示例服務(wù)。
安裝和使用 Microsoft 動態(tài)緩存服務(wù)不會排除對 Microsoft Windows 的支持。
您可以從以下 Microsoft 網(wǎng)站獲得服務(wù)和源的代碼:
若要確定您的系統(tǒng)是否受此問題,請安裝 SysInternals RamMap 工具。
運行該工具時,選擇使用計數(shù)選項。這將顯示多個列,以顯示當前模式的內(nèi)存使用情況。單擊Active列進行排序使用字節(jié)數(shù),并注意總使用量(Total)。如果排列在頂部的使用計數(shù)是”Metafile”,并使用了大部分可用的內(nèi)存;蛘吣龅”癥狀”一節(jié)中描述的系統(tǒng)文件緩存問題?梢詫ζ溥M行如此驗證: 即通過使用性能監(jiān)視器監(jiān)視的Memory\System Cache Resident Bytes計數(shù)器并查看隨著時間的推移不斷增長的緩存用量。
圖 1。存在問題的 RamMap 示例。
圖 2。正常的 RamMap 示例。
如果在性能監(jiān)視器中的Memory\System Cache Resident Bytes計數(shù)器顯示一段時間的上升趨勢,計算機如圖 3 所示出現(xiàn)問題。
圖 3。性能監(jiān)視器輸出示例的計算機遇到問題隨著時間的推移。