任務管理器中一些功能的簡單介紹

任務管理器中一些功能的簡單介紹

表格中的內容來自：http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/core/fneb_mon_oyjs.mspx?mfr=true

在任務管理器的查看->選擇列中，可以更改進程面板中顯示的性能檢測項目。

進程統計項目	Description描述
Base Priority 基本優先級	進程的基本優先級決定了這些進程在CPU的處理隊列中的排列順序。基本優先級由進程本身控制，而不是操作系統指定。操作系統設置、改變進程中線程的動態優先級。可以在任務管理器中設置進程的優先級，更詳細的內容參考“處理器活動分析 ”。
CPU Time CPU時間	從進程開始運行起，所佔用的CPU總時間，以秒計。
CPU Usage CPU佔用	上次跟新到本次更新的時間段內，該進程佔用的CPU時間的百分比。
GDI Objects 圖形設備接口對象數目	進程使用的圖形設備接口（GDI）控件的數目。GDI控件是指，從針對圖形輸出設備的應用程序接口GDI庫中調用的控件。
Handle Count 句柄數	進程的對象列表中對象句柄的數目。
I/O Other I/O其它	進程產生的非讀非寫的輸入輸出操作的數目，包括，文件、網絡和設備I/O。這種操作的一個例子是行使控制功能。不統計指向控制檯的操作（控制檯輸入）。
I/O Other Bytes I/O其它字節數	其它I/O操作傳輸的字節數。
I/O Read Bytes I/O讀取字節數	進程在輸入輸出操作中讀入的字節數。包括文件，網絡和設備I/O。指向終端的操作不在統計之列。
I/O Reads I/O讀取	進程在輸入輸出操作中讀操作的數目。包括文件，網絡和設備I/O。指向終端的操作不在統計之列。
I/O Write Bytes I/O寫入字節數	進程在輸入輸出操作中寫出的字節數。包括文件，網絡和設備I/O。指向終端的操作不在統計之列。
I/O Writes I/O寫入	進程在輸入輸出操作中的寫出操作數。包括文件，網絡和設備I/O。指向終端的操作不在統計之列。
Image Name 映像名稱	進程名。
Memory Usage 內存使用	進程佔用的主內存數，以千字節KB計。
Memory Usage Delta 內存使用增量	兩次統計更新之間，內存佔用量的變化，以KB計。
Nonpaged Pool 非頁面緩衝池	該進程佔用的操作系統內存數，以KB計。操作系統內存中從未分頁到硬盤的部分。分頁是將應用程序內存中的不常用的部分轉移到其它存儲媒介上，通常是轉移到硬盤上。
Page Faults 頁面錯誤	應用程序請求的數據由於不在內存而需要從硬盤上重新讀入的次數。從應用程序啓動開始計數。
Page Faults Delta 頁面錯誤增量	兩次更新間的頁面錯誤增加量。
Paged Pool 頁面池	該進程佔用的操作系統內存數，以KB計。頁面池是可以分頁到硬盤的虛擬內存。頁面池包括所有的用戶內存和系統內存的一部分。
Peak Memory Usage 內存使用峯值	從啓動開始，進程佔用的物理內存峯值。
PID (Process Identifier) 進程標識	應用程序啓動時分配的數字標識。
Thread Count 線程數	應用程序中運行的線程數。
USER Objects 用戶對象	進程佔用的用戶對象數。用戶對象是指窗口管理器中的對象，包括窗口、菜單、光標、圖標、鉤子hooks、加速器、顯示器、鍵盤佈局，以及其它內部對象。
Virtual Memory Size 虛擬內存量	爲該進程分配的虛擬內存（或地址空間）量。

在任務管理器的性能面板中，通過“查看”菜單中選擇“顯示核心時間”，可以查看應用程序調用操作系統服務所佔用的CPU時間，剩餘的時間，即用戶模式，是運行應用程序本身的代碼所佔用的時間。

下表簡單地描述了性能面板中一些統計項目的內容。

Task Manager counts	Description
CPU Usage CPU使用
MEM Usage 內存使用	虛擬內存的使用量（ 虛擬內存（Virtual Memory）是Windows管理所有可用內存的方式）
Total Handles 總句柄數
Total Threads 總線程數
Total Processes 總進程數
Physical Memory: Total 物理內存：總量
Physical Memory: Available 物理內存：可用量	包括清零的，釋放的和待分配內存。
Physical Memory: File Cache 物理內存：文件緩存	Amount of physical memory, in kilobytes, released to the file cache on demand. 文件緩存佔用的物理內存。
Commit Charge: Total 認可用量：總數	所有進程使用的虛擬內存量
Commit Charge: Limit 認可用量：限制	不擴大頁面文件的情況下，可供分配的虛擬內存總量。
Commit Charge: Peak 認可用量：峯值	虛擬內存的峯值用量，如果虛擬內存增大，可能會超過認可用量的限制值。
Kernel Memory: Total 核心內存：總量	頁面和非頁面內存的總量
Kernel Memory: Paged 核心內存：頁面	操作系統佔用的頁面池容量。
Kernel Memory: Nonpaged 核心內存：非頁面	操作系統佔用的非頁面池容量。

關於內存這部分把我弄暈了，對我來說又沒有什麼太重要的意義，算了，有心人可以看下面牛人寫的：

虛擬內存，物理內存，頁面文件，還有任務管理器

[quote]發信人: Hakkk (藍貓淘氣3k問·荷蘭篇), 信區: NewSoftware
標  題: 虛擬內存，物理內存，頁面文件，還有任務管理器
發信站: 水木社區 (Tue Nov 20 21:56:20 2007), 站內

虛擬內存（Virtual Memory）是Windows管理所有可用內存的方式。
對於32位Windows系統，每個進程所用到的虛擬內存地址從0到2^32-1，總容量4GB，
其中2GB是與操作系統以及其他所有進程所共享，
另外2GB分派給進程獨佔（這就是常說的32位Windows中一個進程最多能用2G內存的由來）。

4GB虛擬地址空間（Virtual Address Space，VAS）中，2GB的進程獨佔VAS是進程隔離的，
換句話說，每個進程都可以從RAM或者硬盤上映射到屬於自己的2GB VAS。
所以雖然32位Windows每個進程最多隻能獲得4GB可用虛擬內存，
但是所有進程總和可以使用總量超過4GB的虛擬內存。
可惜XP只支持4GB RAM，也就是說超出部分一定得靠頁面文件補足；
而比如2003企業版通過PAE支持32GB RAM，可以減少頁面文件的用量。
（但單個進程最多仍然只有4GB虛擬內存地址空間，而不是32GB）

所以，一個簡單的計算示例：
三個進程最多能用掉多少VAS？
2GB（共享）＋2GB（獨佔）×3＝8GB

這4GB的虛擬地址空間，按照4KB的大小進行分頁（page），
然後以頁爲單位映射到實際存儲單元中，包括：
·物理內存（RAM）
·頁面文件（Page File，在Win9x中稱爲交換文件Swap File，即win386.swp）
·其他文件自身（比如一些長時間未活動的進程的exe文件自身）
可見，通常人們所說的虛擬內存實際上只是指其中的頁面/交換文件而已，
這是對虛擬內存的一個錯誤的理解。
虛擬內存≠頁面文件

RAM中除了保存最近讀寫的文件緩存（File Cache，相當於Win9x中的Vcache）
主要用來存儲正在使用的程序代碼和數據，
當RAM資源緊張，或者有程序碼或數據長時間未使用時，
XP通常會將非活躍程序碼所在的地址頁映射回程序文件（exe、dll等），
將數據所在的地址頁映射到頁面文件（pagefile.sys）中並拷貝數據，
然後將它們本來佔用的RAM空間釋放。
這個過程稱爲頁出（Page Out）。

當系統讀取某個虛擬內存地址，而該地址所在的頁不在RAM中時，
將產生一個頁面錯誤（Page Fault）中斷，
告訴系統從頁面文件或者程序文件中取回包含該地址的虛擬內存頁，
即將內容拷回到RAM並建立新的虛擬地址映射，並將頁面文件中對應部分標記爲未使用，
這個過程就是頁入（Page In）。
頁入成功的話就是一個Valid Page Fault，否則就是Invalid Page Fault。
前者非常普遍，（可以在任務管理器的進程頁監視到）
而後者是由程序或硬件錯誤引起，
如果發生在進程上會導致非法操作，如果是系統自身則很可能藍屏。

內存用量可以在任務管理器的性能頁中看到。
其中物理內存的總量、可用數等是指安裝的RAM容量和剩餘RAM容量，
而內存使用或者提交更改的總量和限制是指虛擬內存的Commit Limit和Committed Bytes，
可以理解成系統可以使用的虛擬內存總量和當前使用量，
其中總量是由RAM大小＋頁面文件大小決定的。

而在任務管理器的進程頁中，“內存使用”和“虛擬內存大小”造成的誤解很多，
而實際上，這兩個值是對應性能監視器中該進程的Working Set和Private Bytes，

Working Set是指一個進程的4GB虛擬地址空間中被映射到RAM中的部分的大小，
通常是該進程的虛擬內存中的活躍部分。
表面看來這個表述和“進程佔用的RAM大小”沒有太大區別，
但至少有兩種情況導致了例外的發生：
第一種是這部分虛擬內存如果是屬於2G的系統共享虛擬內存，
那麼它映射到的RAM地址可能和其他進程有重複，計算多個進程佔用RAM總和就不正確，
使得所有進程的Working Set之和比實際佔用RAM要大。
第二種是一個進程中可能有同一段RAM內容的多個引用，比如一個文件被loop多次，
此時虛擬空間中會有多段地址被映射到同一段RAM上，
從而造成該進程的Working Set比實際佔用RAM要大。

Private Bytes是一個進程的2GB獨佔虛擬地址空間中用到的部分的大小，
無論這部分是在RAM中還是在頁面文件中，甚至是在exe、dll等文件中。
所以，任務管理器進程頁中的虛擬內存絕對不反映pagefile.sys的用量。

所以，任務管理器無論是進程頁還是性能頁都不能直接反映pagefile的使用情況，
諸如“關掉pagefile還能看到虛擬內存”之類的疑問，應該很清楚了。

下面是一個簡單圖示，
兩個進程，各自擁有2G獨佔VAS，共同擁有2G共享VAS，
W代表映射到RAM中的部分（Working Set），P代表頁出的部分。

         0 …………………2GB獨佔內存……………… 2G ………2GB共享內存……… 4G
進程1    |--PPPP---------------WW-----PPPP--------|
             ////              ||      ////
              ////             ||       ////
               ////            ||        ||||     |--PPPPPPPPPPPP--WWWWWWWW--|
           exe2 exe1   dll  RAMemory pagefile.sys    ||||||||||||  ||||||||
           ||||       ///   ///  /     ||    |     共享內核/dll等 共享RAM空間
進程2    |-PPPP------PPP---WW--WW------PP----P----|

然後，任務管理器的進程頁中的“內存”就是上圖中的W，
所以所有進程的內存項加起來肯定比實際用的RAM大，因爲有共享部分
此外還有重複引用，比如上圖中進程2獨佔內存中第二和第三個W指向同一段RAM空間。

而任務管理器進程頁中的“虛擬內存”就是上圖中右半部分，“獨佔VAS”。
可見pagefile只是其中的一部分，而RAM，只要用於獨佔VAS，一樣計入了該處“虛擬內存”
。

最後，實際的頁面文件用量（pagefile.sys中實際使用部分），
可以在性能監視中看到，即Paging File下的% Usage和% Usage Peak
配合當前pagefile.sys的大小就可以計算出字節數，
這個值可以做爲設定頁面文件最小值的一個參考，
而不是用任務管理器進程頁的所有進程的虛擬內存大小相加做爲頁面文件最小值的參考。