發新話題

深入探索 Windows Vista 核心

深入探索 Windows Vista 核心

文章分三部分

第一部分

瞭解 Windows Vista 內核:第一部分
這是系列文章的第一部分,探討的是 Windows Vista 內核中的新增內容。在這一期中,我將著重說明在進程、線程和 I/O 方面的更改;在將來幾期內容中將涉及到內存管理、啟動和關閉、可靠性和恢復以及安全性方面的內容。
本文的範圍僅限於對 Windows Vista 內核的更改,尤其是對 Ntoskrnl.exe 和與其緊密關聯的組件的更改。請記住,在 Windows Vista 中還存在許多其他重大更改,但這些卻超出了內核的範圍,因此本文將不予以說明。其中包括對外殼(如集成的桌面搜索)、網絡(如新的 IPv6 堆棧和雙向防火牆)和下一代圖形模型(如 Aero Glass、Windows Presentation Foundation、桌面窗口管理器和新圖形驅動程序模型)的改進。而且未涉及的內容還包括新的 Windows 用戶模式和內核模式驅動程序框架(UMDF 和 KMDF),因為在較早的 Windows 版本上它們在後級別才是可安裝的。
CPU 時鐘週期計數
Windows Vista 包含了進程和線程方面的大量增強功能,其中包括使用 CPU 時鐘週期計數器以較公平地進行 CPU 分配,以及使用新的多媒體類計劃程序服務 (MMCSS),它有助於媒體應用程序提供穩定的播放。
所有 Windows NT 版本,包括 Windows Vista 程序在內,大約在每 10 ms 或 15 ms(毫秒)執行一次間隔計時器中斷例程,間隔取決於硬件平台。該例程查看它所中斷的線程並更新線程的 CPU 使用統計數據,就好像該線程在整個間隔期間都在運行,而事實上,線程可能僅在間隔就要結束前才開始執行。而且,從技術上講,可能已經為線程分配了 CPU,但卻一直沒有機會運行,因為執行的是硬件和軟件中斷例程。
雖然對於報告線程和進程 CPU 使用情況的診斷工具來說,基於時鐘的時間計算是一個好方法,但是,若由線程計劃程序使用該方法將導致不公平的 CPU 分配。默認情況下,Windows 客戶端版本上的線程最多可運行 2 個時鐘節拍(如果是在前台中運行則為 6 個時鐘節拍)。然而,根據線程在系統上的行為和其他活動,線程實際上可能在 CPU 上根本沒有時間或是最多得到 6 個時鐘節拍(如果是在前台中運行則為 18 個時鐘節拍)。
圖 1 顯示了兩個具有相同優先級的線程同時準備好運行時發生的不公平情況。計劃程序假定線程 A 在整個間隔期間內運行時,線程 A 一直運行到下一時間片間隔過期,因此也就可以確定線程 A 已運行完畢。而且,在線程 A 運行期間發生的中斷應由線程 A 完全負責。在下一間隔內,計劃程序挑選線程 B 來接續,並且要在整個間隔內運行。

圖 1 不公平的線程計劃
在 Windows Vista 中,計劃程序使用現代處理器的時鐘週期計數器寄存器精確地跟蹤線程所執行的 CPU 時鐘週期數。通過估計 CPU 在一個時鐘間隔內能夠執行的時鐘週期數,它可以更準確地在 CPU 上佈置輪循。另外,Windows Vista 計劃程序不會根據線程的輪循計數中斷執行。這就意味著,在 Windows Vista 上,線程始終會得到至少一次在 CPU 上運行的機會,而且永遠不會執行多個額外時鐘間隔,這使應用程序的行為更公平,也更具確定性。圖 2 顯示了 Windows Vista 如何響應圖 1 中所示的情況,方法是為兩個線程提供至少一個時間片的執行間隔。

圖 2 Windows Vista 基於時鐘週期的計劃

訪客無法瀏覽此圖片或連結,請先 註冊登入會員
」邊欄說明了用戶如何通過使用 Process Explorer 實用工具監視進程的 CPU 時鐘週期使用情況。
多媒體類計劃程序服務
用戶期望多媒體應用程序(包括音樂和視頻播放器)能夠提供無縫的播放體驗。然而,其他同時運行的應用程序(如防病毒、內容索引甚至是郵件客戶端)對 CPU 的要求會帶來不和諧的因素。為了提供更佳的播放體驗,Windows Vista 引入 MMCSS 來管理多媒體線程的 CPU 優先級。
像 Windows Media Player 11 這樣的多媒體應用程序使用能夠表明其多媒體特性的新 API,通過 MMCSS 進行註冊,它必須與下列按名稱排列的註冊表項之一匹配: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\Tasks
各種任務註冊表項可指定與不同多媒體類型相關聯的線程為 CPU 和圖形處理器資源獲取的首選級別(儘管在 Windows Vista 中未實現圖形處理器資源管理)。圖 3 顯示了在乾淨安裝 Windows Vista 後其中一個任務註冊表項的內容,儘管第三方開發人員能夠添加自己的任務定義。
[url=javascript:ToggleImages('338723006', '189403006');]

[/url]
圖 3 多媒體類計劃程序音頻任務定義 (單擊該圖像獲得較小視圖)
[url=javascript:ToggleImages('189403006', '338723006');]

[/url]
圖 3 多媒體類計劃程序音頻任務定義 (單擊該圖像獲得較大視圖)
在 %SystemRoot%\System32\Mmcss.dll 中實現且在服務主機 (Svchost.exe) 進程中運行的 MMCSS 具有可在優先級 27 運行的優先級管理線程。(Windows 中線程優先級的範圍是從 0 到 31。)此線程將已註冊的多媒體線程的優先級推進到另一個範圍內,該範圍與任務註冊表項(如
訪客無法瀏覽此圖片或連結,請先 註冊登入會員
所示)的計劃類別值相關聯。在 Windows 中,線程優先級 16 及更高級別處在實時優先級範圍內並且高於系統上的其他所有線程(除了內核的內存管理器工作線程,該線程在優先級 28 和 29 運行)。僅管理帳戶(如執行 MMCSS 的「本地系統」帳戶)具有設置實時線程優先級所需的提升優先級權限。
在播放音頻文件時,Windows Media Player 註冊音頻任務線程;在播放視頻時,Windows Media Player 註冊播放任務線程。對於已經指明它們在擁有前台窗口的進程中運行時並且在將任務的定義註冊表項中的 BackgroundOnly 值設置為 True 時將同時傳遞流的所有線程,MMCSS 服務會對其進行提升。
但是在 MMCSS 想要幫助多媒體線程獲得所需的 CPU 時間的同時,它還想確保其他線程至少也能獲得一些 CPU 時間,這樣,系統和其他應用程序才能保持響應能力。因此,MMCSS 為其他活動保留了一定百分比的 CPU 時間,並在以下註冊表值中進行指定: HKLM\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\SystemResponsiveness
默認情況下,此比例為 20%;MMCSS 監視 CPU 的使用情況,以確保在其他線程需要 CPU 時,在 10 ms 期間內提升多媒體線程所佔的時間不超過 8 ms。為了使多媒體線程不佔用剩下的 2 ms,計劃程序將其優先級設置在 1-7 級的範圍內。
您可以通過閱讀「
訪客無法瀏覽此圖片或連結,請先 註冊登入會員
」邊欄瞭解 MMCSS 是如何提升線程優先級的。
基於文件的符號鏈接
Windows Vista I/O 的相關更改包括基於文件的符號鏈接、更有效的 I/O 完成處理、對 I/O 取消的全面支持以及優先 I/O。
終於在 Windows Vista 中見到符號文件鏈接(或如在 UNIX 中那樣稱作軟鏈接)了,許多人認為它是 NTFS 中缺少的文件系統功能。NTFS 的 Windows 2000 版本引入了符號目錄鏈接(稱為目錄接合),允許用戶創建指向其他目錄的目錄,但是在 Windows Vista 版本發佈之前,NTFS 僅支持文件的硬鏈接。
Windows 解決符號鏈接和目錄接合所採用的方式的最大區別在於處理所發生的位置。Windows 在本地系統上處理符號鏈接,即使它們引用遠程文件服務器上的位置。Windows 在服務器本身上處理引用遠程文件服務器的目錄接合。因此,服務器上的符號鏈接可以引用僅從客戶端才能訪問的位置(如其他客戶端卷),而目錄接合則做不到。為了解決這個問題,Windows Vista 支持適用於文件和目錄的新符號鏈接類型。
已經對許多文件系統命令進行了更新,以瞭解符號鏈接的含義。例如,Delete 命令知道不要跟隨鏈接(這樣會導致目標的刪除),而是要刪除鏈接。然而,由於不是所有的應用程序都能正確地處理符號鏈接,因此,創建符號鏈接需要新的創建符號鏈接權限,而默認情況下,僅有管理員才具有該權限。
您可以在命令提示符下使用 Mklink 命令創建符號鏈接。命令提示符的內置目錄命令通過用  標記符號鏈接並在括號中顯示目標的方式標識符號鏈接,如圖 5 中所示。Windows 資源管理器也可識別符號鏈接,並使用快捷方式箭頭顯示。可以通過將「鏈接目標」列添加到瀏覽窗口中來查看資源管理器中的鏈接目標。
[url=javascript:ToggleImages('296677008', '175400008');]

[/url]
圖 5 使用 Mklink 創建符號鏈接 (單擊該圖像獲得較小視圖)
[url=javascript:ToggleImages('175400008', '296677008');]

[/url]
圖 5 使用 Mklink 創建符號鏈接 (單擊該圖像獲得較大視圖)
I/O 完成和取消
對 I/O 系統所做的大量更改可改進服務器應用程序的性能。這些應用程序通常使用稱為完成端口的同步對像來等待異步 I/O 請求的完成。在 Windows Vista 之前,當此類 I/O 完成時,已發佈 I/O 的線程將執行 I/O 完成工作,這可切換到線程所屬的進程並中斷所有正在進行的其他工作。然後,I/O 系統將更新完成端口的狀態,以喚醒正在等待完成端口進行狀態更改的線程。
在 Windows Vista 上,I/O 完成處理不必非由已發佈 I/O 的線程執行,但是必須由等待完成端口將其喚醒的線程來執行。這個相對較小的更改避免了不必要的線程計劃以及可能造成應用程序和系統整體性能下降的上下文切換。為了進一步提高性能,服務器可以從一個請求的完成中檢索多個 I/O 操作的結果,避免轉換到內核模式。
從最終用戶的角度來看,I/O 系統中最可見的更改可能是 Windows Vista 所支持的取消同步 I/O 操作。如果曾經執行過 net view 命令或試圖使用 Windows XP 或 Windows Server 2003 訪問過脫機遠程系統的共享,您就已經體驗到了無法取消的 I/O 操作問題:直到網絡超時過期後,命令或文件瀏覽器才能響應。應用程序沒有選擇,只能等待,直至操作失敗,因為它沒有辦法告知正在執行 I/O 的設備驅動程序不需再理會 I/O 了。
在 Windows Vista 中,大多數 I/O 操作都可以取消,包括 Net View 和資源管理器使用的打開文件 I/O。然而,必須更新應用程序以響應最終用戶的取消 I/O 請求,而且許多與具有超時設置的設備進行交互的 Windows Vista 實用工具已得到必要的支持。例如,實際上由每個 Windows 應用程序(包括第三方應用程序)使用的文件打開和保存對話框現在允許在試圖顯示文件夾內容時啟用「取消」按鈕。在按 Ctrl+C 時,Net 命令也可取消其同步 I/O。
可以通過在 Windows Vista 上打開命令提示符並鍵入以下內容來查看 I/O 取消所帶來的好處: net view (\\nonexistentmachine)
在 Windows 試圖聯繫不存在的系統時該命令將掛起,但可以通過鍵入 Ctrl+C 來終止該命令。在 Windows XP 中,Ctrl+C 不會產生影響,並且直到網絡操作超時後命令才會返回。
在 Windows 以前的版本中會引發用戶問題的另一類 I/O 就是設備驅動程序不能正確取消的 I/O,因為設備驅動程序輕易不會知道它們應該這樣做。如果曾經終止過進程,但隨後發現它在進程查看工具中有所延遲,那麼,您已經親眼目睹了設備驅動程序無法對進程終止做出響應,並且取消由未完成進程發佈的 I/O 這兩個過程。直到所有進程的 I/O 已經完成或已被取消,Windows 才能執行最終進程清理。在 Windows Vista 中,設備驅動程序能夠很容易地註冊進程終止的通知,因此,大多數無法終止的進程問題也就迎刃而解了。

[ 本帖最後由 midi78578 於 2007-3-4 03:32 編輯 ]

TOP

I/O 優先級
雖然 Windows 始終支持 CPU 使用情況的排列優先級,但是卻未包括 I/O 優先級這一概念。如果沒有 I/O 優先級,搜索索引、病毒掃瞄和磁盤碎片整理等後台活動會對前台操作的響應性帶來嚴重的影響。例如,用戶在另一進程正在執行磁盤 I/O 時啟動應用程序或打開文檔,則該用戶將體驗到延遲,因為前台任務要等待磁盤訪問。同樣的干擾也會影響到多媒體內容(如硬盤上的歌曲)流播放的質量。
為了有助於前台 I/O 操作獲取首選項,Windows Vista 引入了兩個全新類型的 I/O 優先級排列:單獨 I/O 操作的優先級和 I/O 帶寬保留。Windows Vista I/O 系統內部包括對五個 I/O 優先級的支持,如
訪客無法瀏覽此圖片或連結,請先 註冊登入會員
所示,但是僅使用了四個優先級(Windows 的未來版本可能支持「高」優先級)。
I/O 具有「中等」默認優先級,內存管理器想要在低內存情況下將髒內存數據寫到磁盤中從而為其他數據和代碼在 RAM 中留出空間時,將使用「關鍵」優先級。Windows Task Scheduler 將具有默認任務優先級的任務 I/O 優先級設置為「低」,並將由執行後台處理的應用程序(為 Windows Vista 而編寫)指定的優先級設置為「非常低」。所有 Windows Vista 後台操作(包括 Windows Defender 掃瞄和桌面搜索索引)均使用「非常低」I/O 優先級。
系統存儲類設備驅動程序 (%SystemRoot%\System32\Classpnp.sys) 強制使用 I/O 優先級,因此也就自動應用於指向大多數存儲設備的 I/O。類和其他存儲驅動程序將「中等」I/O 插入到隊列內優先級為「低」和「非常低」的 I/O 之前,但是至少應每秒發佈一個等待「低」或「非常低」I/O 的操作,這樣後台進程才可以向前進行。使用「非常低」I/O 讀取數據還會使緩存管理器立刻將修改寫入磁盤,並繞過讀取操作的預讀邏輯,否則它會優先從正在訪問的文件中進行讀取。請將邊欄「
訪客無法瀏覽此圖片或連結,請先 註冊登入會員
」作為使用 Process Monitor 實用工具的「非常低」I/O 優先級的示例瞭解一下。
Windows Vista 帶寬保留支持對於媒體播放機應用程序非常有用,Windows Media Player 將其連同 MMCSS 優先級提升一起使用,以提供對本機內容近乎穩定的播放體驗。媒體播放機應用程序要求 I/O 系統確保它能夠以指定速率讀取數據,如果設備能夠以請求的速率傳遞數據而且現有保留也允許的情況下,它將針對發佈 I/O 的頻率以及 I/O 應具有的大小兩方面為應用程序提供指導。I/O 系統不會為其他 I/O 提供服務,除非它能夠滿足在目標存儲設備上做出保留的應用程序的要求。
在 I/O 系統中值得一提的一個最終更改與 I/O 操作的大小有關。因為第一版 Windows NT、內存管理器和 I/O 系統已將單獨存儲 I/O 請求所處理的數據數量限制為 64KB。因此,即使應用程序發佈了一個更大的 I/O 請求,也會被分解為最大大小為 64KB 的多個請求。每個 I/O 都導致了轉換到內核模式的開銷並在存儲設備上啟動 I/O 傳輸,因此在 Windows Vista 中,存儲 I/O 請求大小將不再受限。已對一些 Windows Vista 用戶模式組件進行了修改,以利用對更大 I/O 的支持,包括資源管理器的複製功能和命令提示符的 Copy 命令(現在發佈 1MB 的 I/O)。
預告
現在,您已經瞭解了 Windows Vista 內核功能增強的兩個方面。預期您可以在《Windows Internals》(Windows 內部結構)(與 David Solomon 共同執筆)一書的下一版本中瞭解到更詳細的信息,計劃與 Windows Server 的下一版本(代碼名為「Longhorn」)同時推出。在下期內容中,我將繼續通過探討內存管理以及系統的啟動和關閉來為您介紹新的內核。
妳的苦惱,我可以替妳解決.讓我修理你的主機一次500元

TOP

瞭解 Windows Vista 核:第 2 部分

上個月,我在這個由三部分構成的系列文章的第一部分,分析了 Windows Vista 內核在進程和 I/O 方面的增強功能。
這一次,我將涵蓋到 Windows Vista 對內存管理方式的提升以及系統啟動、關閉和電源管理方面的主要改進(
訪客無法瀏覽此圖片或連結,請先 註冊登入會員
)。
Windows 隨著每個發行版本的問世都在可伸縮性和性能方面進行了改進,Windows Vista 也不例外。Windows Vista 內存管理器包含了大量增強功能,例如,更大範圍地使用無鎖同步技術、鎖定粒度更細、數據結構包更緊密,分頁 I/O 更大、增加了對現代 GPU 內存體系結構的支持,並更有效利用了硬件的轉換旁路緩衝器。另外,Windows Vista 內存管理如今還針對不同工作負荷的要求提供動態地址空間分配。
以下四種採用新技術的性能增強型功能首次在 Windows Vista 操作系統上登台亮相:SuperFetch、ReadyBoost、ReadyBoot 和 ReadyDrive。本文稍後將詳細討論這些功能。
動態內核地址空間
Windows 以及其上所運行的應用程序佔用的地址空間已經達到了 32 位處理器的地址空間極限。默認情況下,Windows 內核被限制在 2GB,或者是 32 位虛擬地址空間總量的一半,另一半則預留給當前正在 CPU 中運行線程的進程使用。在其自己的那一半虛擬地址空間中,內核必須映射其自身、設備驅動程序、文件系統緩存、內核堆棧、每會話代碼數據結構,以及由設備驅動程序分配的非分頁(鎖定的物理內存)緩衝區和分頁緩衝區。在 Windows Vista 推出之前,內存管理器在引導時確定針對這些用途分配多少地址空間,但這種不變性有時會造成其中某一區域空間被佔滿,而其他區域仍有大量可用空間的情況。區域空間被用盡會導致應用程序出現故障,並會妨礙設備驅動程序完成 I/O 操作。
在 32 位 Windows Vista 中,內存管理器動態管理內核的地址空間,根據工作負荷的具體需求為各種用途分配和釋放空間。這樣,用於存儲分頁緩衝區的虛擬內存量會隨著設備驅動程序需求量增加而增加,並會在驅動程序釋放它時縮小。因此,Windows Vista 將能夠處理更大範圍的工作負荷,同樣,即將推出的代號為「Longhorn」的 32 位版本 Windows Server 也將升級到可以處理更多的並行終端服務器用戶。
當然,在 64 位 Windows Vista 系統上,地址空間約束目前還不屬於實質性的限制,因此,在將這些約束配置為相應最大值時,不需要對其進行任何特殊處理。
內存優先級
就像 Windows Vista 添加 I/O 優先級(如上一部分中所述)一樣,它還實現內存優先級。要瞭解 Windows 如何使用內存優先級,就需要掌握內存管理器如何實現其內存緩存(稱為「待機列表」)。在 Windows Vista 之前的所有 Windows 版本中,當某個進程所擁有的物理頁面(大小一般為 4KB)被系統回收時,內存管理器通常將該頁面置於「待機列表」末尾。如果進程想要再次訪問該頁面,內存管理器會從「待機列表」獲取該頁面,然後將其重新分配給該進程。如果進程想要使用物理內存的新頁面,但沒有可用的內存,則內存管理器會為其提供「待機列表」前端的頁面。此方案基本上對待機列表中的所有頁面都同等對待,僅按頁面被置於列表中的時間來對它們進行排序。
在 Windows Vista 上,內存的每個頁面都具有一個在 0 到 7 之間的優先級,這樣,內存管理器會將「待機列表」劃分為八個列表,每一個都用來存儲具有特定優先級的頁面。當內存管理器想要從「待機列表」中獲取某一頁面時,它會先從低優先級列表獲取頁面。頁面的優先級通常反映的是第一個導致該頁面分配的線程的優先級。(如果頁面是共享的,它反映的就是共享線程的最高內存優先級。)線程會從其所屬的進程繼承它的頁面優先級值。當內存管理器預見到某一進程要訪問內存時,會將低優先級用於它從磁盤推測性讀取的頁面。
默認情況下,進程的頁面優先級值為 5,但應用程序和系統可通過函數更改進程和線程的頁面優先級值。只有從宏觀上理解頁面的相對優先級時,才能意識到內存優先級的真正價值,也就是 SuperFetch 所發揮的作用。
SuperFetch
內存管理器的重大改變體現在它對物理內存的管理方式。先前版本 Windows 所使用的「待機列表」管理有兩個局限性。首先,頁面的優先化僅取決於進程最近過去的行為,而不會預見到它們未來的內存需求。其次,用於優先化的數據僅限定於進程在任意給定時刻所擁有的頁面列表。這兩個缺點會導致出現「午餐後綜合症」之類的狀況,即您離開計算機一段時間,但需要內存密集型的系統應用程序在此期間一直都在運行(例如病毒掃瞄或磁盤碎片整理)。此應用程序會強制您的活動應用程序已在內存中進行緩存處理的代碼和數據由內存密集型活動重寫。等您回來後,就會發現性能變得非常緩慢,因為各應用程序必須從磁盤請求它們的數據和代碼。
Windows XP 採用了預取支持,該功能基於以前的引導和應用程序啟動來執行大規模的磁盤 I/O,以向內存預加載所預期到的代碼和文件系統數據,從而改進了引導和應用程序啟動性能。Windows Vista 憑借 SuperFetch 又向前邁進了一大步,SuperFetch 是一種通過歷史信息和前瞻性內存管理來增強「least-recently accessed」(最近最少訪問的)方法的內存管理方案。
SuperFetch 作為在服務主機進程 (%SystemRoot%\System32\Svchost.exe) 內運行的 Windows 服務在 %SystemRoot%\System32\Sysmain.dll 中實現。該方案依賴於內存管理器提供的支持,因此它可以檢索頁面使用歷史,以及引導內存管理器將來自磁盤文件或分頁文件的數據和代碼預加載到「待機列表」中,並為各頁面指定優先級。SuperFetch 服務基本上是將頁面跟蹤擴展到曾經存儲在內存中但已被內存管理器重新使用以為新數據和代碼讓出空間的數據和代碼。該服務會將這一信息存儲在 %SystemRoot%\Prefetch 目錄中擴展名為 .db 的場景文件中(位於用於優化應用程序啟動的標準預取文件旁邊)。在對內存使用情況的這種深入瞭解基礎上,SuperFetch 可在物理內存變為可用時預加載數據和代碼。
只要內存變為可用(例如,當某應用程序退出或釋放內存時),SuperFetch 便會要求內存管理器提取最近被驅出的數據和代碼。這將以每秒少數幾頁的速率完成,並且 I/O 的優先級為「非常低」,以便預加載操作不會影響用戶或其他活動應用程序。因此,如果您離開計算機去享用午餐,並且某個內存密集型的後台任務導致活動應用程序的代碼和數據在您離開期間被驅出內存,則 SuperFetch 通常會在您回來之前將所有或大多數代碼和數據返回到內存中。SuperFetch 還包含了對休眠、待機、快速用戶切換 (FUS) 和應用程序啟動的特定場景支持。例如,當系統處於休眠狀態時,SuperFetch 會將數據和代碼存儲在它預期(基於以前的休眠)將在後續恢復期間被訪問的休眠文件中。相比之下,當您恢復 Windows XP 時,先前緩存的數據在被引用時必須從磁盤重新讀取。
請參閱邊欄「觀察 SuperFetch」以簡單瞭解 SuperFetch 如何影響可用內存。
觀察 SuperFetch
在您使用 Windows Vista 系統一段時間後,您會發現任務管理器「性能」頁面上的「可用物理內存」計數器的數值很低。這是因為 SuperFetch 和標準 Windows 緩存處理使用了所有可用物理內存來緩存磁盤數據。例如,在您首次引導時,如果您立即運行任務管理器,則您會注意到,可用內存值會隨著已緩存內存量的增加而減少。如果您運行一個內存需求很大的程序,然後退出該程序(分配大量內存並在之後釋放內存的任何免費軟件「RAM 優化程序」都適用),或者剛剛複製了一個非常大的文件,則在系統回收已釋放內存時可用內存量將增加,並且物理內存用量圖將下降。但隨著時間的過去,SuperFetch 會用被強制離開內存的數據重新填充緩存,這樣,已緩存內存量將增加,可用內存量將下降。
[url=javascript:ToggleImages('476461023', '413400023');]

[/url]
Watching memory  (單擊該圖像獲得較小視圖)
[url=javascript:ToggleImages('413400023', '476461023');]

[/url]
Watching memory  (單擊該圖像獲得較大視圖)
妳的苦惱,我可以替妳解決.讓我修理你的主機一次500元

TOP

ReadyBoost
CPU 和內存的速度快到超越了硬盤的速度,因此磁盤是一個常見的系統性能瓶頸。隨機磁盤 I/O 成本尤為高昂,因為磁頭尋道時間約為 10 毫秒,這對於現今的 3GHz 處理器來說有些漫長。儘管 RAM 是用於緩存磁盤數據的理想選擇,但它的成本也相對較高。不過,閃存通常較為便宜,它隨機讀取的速度最高可比典型硬盤快 10 倍。因此,Windows Vista 中加入了一個名為 ReadyBoost 的功能來利用閃存存儲設備,方法是在這些設備上創建一個邏輯上介於內存和磁盤之間的中間緩存層。
ReadyBoost 由一個在 %SystemRoot%\System32\Emdmgmt.dll 中實現的運行於服務主機進程中的服務和一個捲過濾器驅動程序 (%SystemRoot%\System32\Drivers\Ecache.sys) 組成。(Emd 是「外部內存設備」的簡稱,即 ReadyBoost 在開發期間所使用的工作名稱。)當您將 USB 密鑰之類的閃存設備插入到系統中時,ReadyBoost 服務會查看該設備以確定其性能特徵並將測試結果存儲在 HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Emdmgmt 中(如圖 1 所示)。
[url=javascript:ToggleImages('380759002', '200400002');]

[/url]
Figure 1 ReadyBoost device test results in the registry (單擊該圖像獲得較小視圖)
[url=javascript:ToggleImages('200400002', '380759002');]

[/url]
Figure 1 ReadyBoost device test results in the registry (單擊該圖像獲得較大視圖)
如果您還未使用設備進行緩存處理,並且新設備大小介於 256MB 和 32GB 之間、對於 4KB 隨機讀取的傳輸率為 2.5MB/s 或更高、對於 512KB 隨機寫入的傳輸率為 1.75MB/s 或更高,則 ReadyBoost 將詢問您是否想要將高達 4GB 的存儲空間專門用於進行磁盤緩存。(儘管 ReadyBoost 可以使用 NTFS,它還是會將最大緩存大小限制在 4GB,以適應 FAT32 限制。)如果您同意,該服務便會在設備的根目錄下創建一個名為 ReadyBoost.sfcache 的緩存文件,並要求 SuperFetch 在後台預先填充緩存。
在 ReadyBoost 服務對緩存進行初始化之後,Ecache.sys 設備驅動程序會將所有讀寫數據截取到本地硬盤捲(例如 C:\),並將要寫入的所有數據複製到該服務創建的緩存文件中。Ecache.sys 會將數據壓縮,壓縮比通常達到 2:1,這樣,4GB 的緩存文件通常將包含 8GB 數據。驅動程序會聯合使用高級加密標準 (AES) 和一個隨機生成的每引導會話密鑰對其寫入的每個塊進行加密,以在將設備從系統移除的情況下保證緩存中數據的保密性。
當 ReadyBoost 確定可從緩存滿足隨機讀取需求時,它便會從那裡向隨機讀取提供服務,但由於硬盤的有序讀取訪問要勝過閃存,因此,它允許有序訪問模式中的讀數據直接移至磁盤,即使該數據位於緩存中。
ReadyBoot
如果系統的內存不到 512MB,則 Windows Vista 會使用與 Windows XP 一樣的引導時預取,但如果系統的 RAM 為 700MB 或以上,它便會使用 RAM 內緩存來優化引導進程。緩存的大小取決於可用 RAM 總量,但這足以創建適當的緩存,並還可以為系統留出要順利引導所需的內存。
在每一次引導後,ReadyBoost 服務(就是剛剛介紹的用於實現 ReadyBoost 功能的服務)會使用空閒 CPU 時間來為下一次引導計算引導時緩存計劃。它會分析來自前五次引導的文件跟蹤信息,並標識出訪問了哪些文件以及這些文件在磁盤上的位置。該服務將已處理的跟蹤信息以 .fx 文件形式存儲在 %SystemRoot%\Prefetch\Readyboot 中,並將緩存計劃保存在 HKLM\System\CurrentControlSet\Services\Ecache\Parameters 下的 REG_BINARY 值(這些值針對它們所引用的內部磁盤捲而命名)中。
緩存由實現 ReadyBoost 緩存處理的同一設備驅動程序 (Ecache.sys) 實現,但緩存的填充則是由 ReadyBoost 服務在系統引導時帶領完成。儘管引導緩存像 ReadyBoost 緩存一樣進行壓縮,但 ReadyBoost 和 ReadyBoot 緩存管理之間的另一個區別是,在 ReadyBoot 模式下,除了 ReadyBoost 服務的更新之外,緩存不會變為反映在引導期間讀取或寫入的數據。ReadyBoost 服務會在引導開始後 90 秒時(或者在其他內存需求批准它的情況下)將緩存刪除,並將緩存的統計信息記錄在 HKLM\System\CurrentControlSet\Services\Ecache\Parameters\ReadyBootStats 中(如圖 2 所示)。Microsoft 性能測試表明,與舊有 Windows XP 預取器相比,ReadyBoot 使性能提高了約 20%。
[url=javascript:ToggleImages('460789004', '233400004');]

[/url]
Figure 2 ReadyBoot Performance statistics (單擊該圖像獲得較小視圖)
[url=javascript:ToggleImages('233400004', '460789004');]

[/url]
Figure 2 ReadyBoot Performance statistics (單擊該圖像獲得較大視圖)
ReadyDrive
ReadyDrive 是一項利用了名為 H-HDD 的新型混合硬盤驅動器的 Windows Vista 功能。H-HDD 是一種帶有嵌入式非易失性閃存(還稱為 NVRAM)的磁盤。典型 H-HDD 所包含的緩存大小介於 50MB 和 512MB 之間,但 Windows Vista 緩存限制為 2TB。
Windows Vista 使用 ATA-8 命令來定義要在閃存中存放的磁盤數據。例如,Windows Vista 會在系統關閉時將引導數據保存到緩存,從而可以更快速地重新啟動。它還會在系統處於休眠狀態時將某些部分的休眠文件數據存儲在緩存中,以便加速後來的恢復過程。即使在磁盤盤片降速時也會啟用緩存,因此,Windows 可以將閃存用作磁盤寫入緩存,這樣可避免在系統靠電池電源運行時將磁盤盤片加速。使磁盤軸保持關閉狀態可以節省由磁盤驅動器在正常使用期間所消耗的大量電源。

妳的苦惱,我可以替妳解決.讓我修理你的主機一次500元

TOP

引導配置數據庫
Windows Vista 在啟動和關閉方面增強了許多功能。隨著「引導配置數據庫」(BCD) 的採用,啟動功能在存儲系統和 OS 啟動配置、系統啟動進程的新流程和組織、新登錄體系結構以及對延遲式自動啟動服務的支持方面都有所改進。Windows Vista 關閉方面的變化包括 Windows 服務的預關閉通知、Windows 服務關閉排序以及 OS 對電源狀態轉換的管理方式的重大改變。
啟動進程的最明顯變化之一是,系統卷的根目錄中沒有了 Boot.ini。這是因為,引導配置現在存儲在 BCD 中(在先前版本的 Windows 上,它存儲在 Boot.ini 文本文件中)。Windows Vista 使用 BCD 的其中一個原因是,BCD 將 Windows 支持的兩個當前引導體系結構合為了一體:主引導記錄 (MBR) 和可擴展固件接口 (EFI)。MBR 通常由 x86 和 x64 桌面系統使用,而 EFI 則由基於 Itanium 的系統使用(但在不久的將來,桌面 PC 很有可能會附帶 EFI 支持)。BCD 對固件進行了抽像化,並具有超越 Boot.ini 的其他優點,例如,對 Unicode 字符串和備用預引導可執行文件的支持。
BCD 實際上存儲在磁盤上的某個加載到 Windows 註冊表中以通過註冊表 API 進行訪問的註冊表配置單元中。在 PC 上,Windows 將其存儲在系統捲上的 \Boot\Bcd 中。在 EFI 系統上,它位於 EFI 系統分區上。在加載了該配置單元後,它會在 HKLM\Bcd00000000 下顯示,但因其內部格式沒有文檔記錄,所以編輯它時需要使用 %SystemRoot%\System32\Bcdedit.exe 之類的工具。也可通過 Windows Management Instrumentation (WMI) 將用來操縱 BCD 的接口提供給腳本和自定義編輯器使用,並且可以使用「Windows 系統配置實用程序」(%SystemRoot%\System32\Msconfig.exe) 來編輯或添加基本參數(如內核調試選項)。
BCD 將平台範圍的引導設置(例如,默認 OS 選擇和引導菜單超時時間)與 OS 特定的設置(例如,OS 引導選項和 OS 引導加載器的路徑)分割開來。例如,圖 3 顯示了在您未使用命令行選項運行 Bcdedit 時,BCD 會在輸出上部的「Windows 引導管理器」部分顯示平台設置,接著在「Windows 引導加載器」部分顯示 OS 特定的設置。
[url=javascript:ToggleImages('472677006', '278400006');]

[/url]
Figure 3 Settings displayed in BCDEdit (單擊該圖像獲得較小視圖)
[url=javascript:ToggleImages('278400006', '472677006');]

[/url]
Figure 3 Settings displayed in BCDEdit (單擊該圖像獲得較大視圖)
當您引導 Windows Vista 安裝時,這個新方案會將在先前版本 Windows 上由操作系統加載器 (Ntldr) 處理的任務劃分為兩種不同的可執行文件:\BootMgr 和 %SystemRoot%\System32\Winload.exe。Bootmgr 會讀取 BCD 並顯示 OS 引導菜單,而 Winload.exe 會處理操作系統加載。如果您要執行乾淨引導,則 Winload.exe 會加載引導啟動設備驅動程序和核心操作系統文件(包括 Ntoskrnl.exe),並將控制權移交給操作系統;如果系統要從休眠狀態恢復,則 Winload.exe 會通過執行 %SystemRoot%\System32\Winresume.exe 將休眠數據加載到內存中並恢復 OS。
Bootmgr 還包含對其他預引導可執行文件的支持。Windows Vista 還隨帶了 Windows 內存診斷 (\Boot\Memtest.exe),該工具已被預配置為用於檢查 RAM 性能狀況的選項,但第三方可以添加其自己的預引導可執行文件,以作為將在 Bootmgr 的引導菜單中顯示的選項使用。
啟動進程
在先前版本的 Windows 中,各種系統進程之間的關係並不直觀。例如,在系統引導時,交互登錄管理器 (%SystemRoot%\System32\Winlogon.exe) 會啟動「本地安全機構子系統服務」(Lsass.exe) 和「服務控制管理器」(Services.exe)。此外,Windows 會使用一個名為 Session 的命名空間容器來隔離在不同登錄會話中運行的進程。但在推出 Windows Vista 之前,登錄到控制台的用戶共享的是 Session 0(即,由系統進程使用的會話),這就造成了潛在的安全問題。例如,如果某個運行於 Session 0 中的編寫拙劣的 Windows 服務在交互式控制台上顯示一個用戶界面,從而允許惡意軟件通過粉碎攻擊之類的方法來攻擊窗口並有可能獲得管理特權,就會引發此類安全問題。
為解決這些問題,若干個系統進程都針對 Windows Vista 進行了重新設計。會話管理器 (Smss.exe) 是在使用先前版本的 Windows 時在引導期間創建的第一個用戶模式進程,但在 Windows Vista 上,會話管理器會啟動自己的另一個實例來配置 Session 0,該會話將獨自供系統進程專用。用於 Session 0 的會話管理器進程將啟動「Windows 啟動應用程序」(Wininit.exe)(一個用於 Session 0 的 Windows 子系統進程 (Csrss.exe)),然後退出。「Windows 啟動應用程序」會通過啟動「服務控制管理器」、「本地安全機構子系統」和一個用來管理計算機的終端服務器連接的新進程(即「本地會話管理器」(Lsm.exe))持續運行。
當用戶登錄到系統上時,初始的會話管理器會創建其自己的一個新實例來配置新會話。新的 Smss.exe 進程會為這個新會話啟動 Windows 子系統進程和 Winlogon 進程。讓主會話管理器使用自己的副本初始化新會話並不會為客戶端系統帶來任何有利條件,但在充當終端服務器的 Windows Server「Longhorn」系統上,可以並行運行多個副本以提高多個用戶的登錄速度。
在這個新的體系結構下,各系統進程(包括 Windows 服務)在 Session 0 中進行了隔離。如果運行於 Session 0 中的某個 Windows 服務顯示一個用戶界面,則「交互服務檢測」服務 (%SystemRoot%\System32\UI0Detect.exe) 會通過在用戶的安全上下文中啟動自己的實例並顯示圖 4 中所示的消息來通知所有登錄的管理員。如果用戶選擇「顯示消息」按鈕,該服務會將桌面切換到 Windows 服務桌面,用戶可在這裡與服務的用戶界面交互,然後再切換回自己的桌面。有關啟動時會出現哪些情況的詳細信息,請參閱邊欄「查看啟動進程關係」。
[url=javascript:ToggleImages('262487008', '215400008');]

[/url]
Figure 4 Service has displayed a window (單擊該圖像獲得較小視圖)
[url=javascript:ToggleImages('215400008', '262487008');]

[/url]
Figure 4 Service has displayed a window (單擊該圖像獲得較大視圖)
查看啟動進程關係
可使用 Sysinternals (microsoft.com/technet/sysinternals) 提供的 Process Explorer 來查看 Windows Vista 的進程啟動樹。
屏幕快照包括「會話」列,您可通過 Process Explorer 的列對話框添加它。突出顯示的進程是初始的 Smss.exe。位於它下面的是 Session 0 的 Csrss.exe 和 Wininit.exe,由於這兩個進程的父進程(用於配置 Session 0 的 Smss.exe 實例)已經退出,因此它們左對齊。Wininit 的三個子進程分別是 Services.exe、Lsass.exe 和 Lsm.exe。
Process Explorer 將一組進程標識為在 Session 1 中運行,也就是我通過遠程桌面連接登錄到的會話。Process Explorer 用藍色突出色來顯示與自身使用相同帳戶運行的進程。最後,將 Session 2 初始化,以為登錄到控制台並創建新登錄會話的用戶做好準備。就是在該會話中,Winlogon 將運行並使用 LogonUI 要求新的控制台用戶「按 Ctrl+Alt+DELETE 進行登錄」,而且在該會話中,Logonui.exe 將要求用戶提供其憑據。
[url=javascript:ToggleImages('487632024', '308400024');]

[/url]
Startup process and session information  (單擊該圖像獲得較小視圖)
[url=javascript:ToggleImages('308400024', '487632024');]

[/url]
Startup process and session information  (單擊該圖像獲得較大視圖)
妳的苦惱,我可以替妳解決.讓我修理你的主機一次500元

TOP

憑據提供程序
即使是登錄體系結構也在 Windows Vista 上發生了變化。在先前版本的 Windows 上,Winlogon 進程會加載在註冊表中指定的「圖形識別與認證」(GINA) DLL 來顯示要求用戶提供其憑據的登錄 UI。遺憾的是,GINA 模式受到了許多限制,包括只能配置一個 GINA、第三方很難編寫完整的 GINA,以及具有非標準用戶界面的自定義 GINA 會改變 Windows 用戶體驗。
而 Windows Vista 使用了新的「憑據提供程序」體系結構來代替 GINA。Winlogon 會啟動一個單獨的進程,即「登錄用戶界面主機」(Logonui.exe),該進程將加載在 HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Authentication\Credential Providers 中配置的憑據提供程序。Logonui 可以並行托管多個憑據提供程序;實際上,Windows Vista 隨帶了交互式 (Authui.dll) 提供程序和智能卡式 (Smart-cardcredentialprovider.dll) 提供程序。為確保統一的用戶體驗,LogonUI 會管理對最終用戶顯示的用戶界面,但它還會允許憑據提供程序指定文本、圖標和編輯控件之類的自定義元素。
延遲式自動啟動服務
如果您曾經在 Windows 系統啟動後立即登錄到系統上,您或許在桌面被完全配置並且您可以與外殼和所啟動的任何應用程序進行交互之前經歷了一些延遲。在您登錄時,「服務控制管理器」會啟動多個被配置為自動啟動服務並因此在引導時激活的 Windows 服務。許多服務都會執行與登錄活動爭用資源的 CPU 密集型初始化和磁盤密集型初始化。為解決此問題,Windows Vista 採用了一個被稱為延遲式自動啟動的新服務啟動類型,如果服務不必在 Windows 引導後立即激活,便可使用該類型。
「服務控制管理器」會在自動啟動服務完成啟動後再啟動配置為延遲式自動啟動的服務,並將這些服務的初始線程優先級設置為 THREAD_PRIORITY_LOWEST。此優先級別會使線程執行的所有磁盤 I/O 都採用「非常低」I/O 優先級。在服務完成初始化後,「服務控制管理器」會將其優先級設置為普通。將延遲式啟動、較低的 CPU 和內存優先級與後台磁盤優先級結合後,大大減少了與用戶登錄間的相互衝突。許多 Windows 服務(包括後台智能傳輸、Windows Update 客戶端和 Windows Media Center)都使用這個新啟動類型來幫助提升引導後的登錄性能。
關閉
困擾著 Windows 服務編寫人員的一個問題是,在 Windows 關閉過程中,默認情況下他們最多只有二十秒鐘的時間來執行清理。Windows Vista 之前的 Windows 版本一直不支持等待所有服務都退出的乾淨關閉,因為存在程序錯誤的服務可能會無限期地阻止關閉。有些服務(例如那些具有與網絡相關的關閉操作或必須將大量數據保存到磁盤的服務)可能需要更多的時間,因此 Windows Vista 允許服務請求預關閉通知。
在 Windows Vista 關閉時,「服務控制管理器」會首先通知那些要求預關閉通知的服務。它將無限期地等待這些服務退出,但如果這些服務存在程序錯誤且沒有響應查詢,則「服務控制管理器」會在三分鐘後放棄並繼續前進。一旦所有這些服務都已退出或超時時間已滿,「服務控制管理器」就會接著對剩餘的服務執行舊有形式的服務關閉。組策略和 Windows Update 服務會在全新的 Windows Vista 安裝中註冊預關閉通知。
組策略和 Windows Update 服務還會使用另一個 Windows Vista 服務功能:關閉排序。各服務始終都可以指定啟動依存性,「服務控制管理器」要服從這些依存性以按照滿足這些依存性的順序來啟動服務,但在 Windows Vista 之前,各服務還無法指定關閉依存性。現在,註冊預關閉通知的服務也可以將其自己插入到存儲在 HKLM\System\CurrentControlSet\Control\PreshutdownOrder 的列表中,「服務控制管理器」將根據它們的相應順序將其關閉。有關這些服務的詳細信息,請參閱邊欄「標識延遲式自動啟動和預關閉服務」。
電源管理
睡眠和休眠屬於其他形式的關閉,自 Windows 2000 將電源管理引入到 Windows NT 系列的 Windows 操作系統後,驅動程序和應用程序方面的問題重重的電源管理一直都是令商務旅行人士苦惱的一件事情。當許多用戶在踏上旅途前合上自己的便攜式計算機外蓋時,都期望計算機系統處於掛起或休眠狀態,但沒想到在到達目的地時,手提箱已經變得灼熱,電池也被用盡,而且還丟失了數據。這是因為 Windows 始終都會詢問設備驅動程序和應用程序是否允許更改電源狀態,只要有一個驅動程序或應用程序未響應,就可能會阻止轉換。
在 Windows Vista 中,內核的電源管理器仍會通知驅動程序和應用程序要更改電源狀態以便它們可以為這些更改做好準備,但不會再請求許可。此外,電源管理器最多會留出 20 秒來等待應用程序對更改通知做出響應,而不是像在先前版本的 Windows 上那樣等待 2 分鐘。因此,Windows Vista 用戶可以更加確信自己的系統會執行休眠和掛起。
預告
正如我先前所說的,這是由三部分組成的系列文章中的第二部分。第一部分介紹了 Windows Vista 內核在 I/O 和進程方面的改進。這一次,我分析了 Windows Vista 在內存管理、啟動和關閉方面的增強。下一次,我將通過介紹內核在可靠性和安全性方面的改變來結束本系列文章。
標識延遲式自動啟動和預關閉服務
內置的 SC 命令在 Windows Vista 得到了更新,以顯示配置為延遲式自動啟動服務的服務:
[url=javascript:ToggleImages('256677025', '151400025');]

[/url]
Using SC to display start type  (單擊該圖像獲得較小視圖)
[url=javascript:ToggleImages('151400025', '256677025');]

[/url]
Using SC to display start type  (單擊該圖像獲得較大視圖)
遺憾的是,SC 命令不會報告已請求預關閉通知的服務,但您可以使用 Sysinternals 提供的 PsService 實用程序來確保服務接受預關閉通知:
[url=javascript:ToggleImages('364677026', '215400026');]

[/url]
Viewing pre-shutdown status  (單擊該圖像獲得較小視圖)
[url=javascript:ToggleImages('215400026', '364677026');]

[/url]
Viewing pre-shutdown status  (單擊該圖像獲得較大視圖)
妳的苦惱,我可以替妳解決.讓我修理你的主機一次500元

TOP

發新話題

本站所有圖文均屬網友發表,僅代表作者的觀點與本站無關,如有侵權請通知版主會盡快刪除。