Linux記憶體管理——vmstat

來源:互聯網
上載者:User

原貼地址:http://finlandrbt.spaces.live.com/blog/cns!70C541D1517F6BAE!987.entry
Linux記憶體管理——vmstat  此文談到的很多東西都值得我在效能測試改進方面參考,特此摘錄,看來在讀源碼時需要對page和cpu調度的策略予以特別關注。現在最希望的就是能看到一些國外的效能監控解決方案。

  ps:剛剛發現設定了<FONT>標籤後會覆蓋掉<DIV>的樣式,bug,好大的bug。

   處理單元是系統中最快的組件之一。在某一時間對單個程式來說保持 100% 的 CPU 佔用率(也就是說,空閑 0%,等待 0%)超過幾秒鐘是相對少見的。甚至在重負載的多使用者系統中,偶爾會出現一些 10 毫秒(ms)的時間段,在其結束時所有線程處於等待狀態。如果監視器長時間地顯示 CPU 佔用率為 100%,則很有可能是某個程式陷入了死迴圈。即使程式“僅僅”是佔用較多資源而不是崩潰了,也需要將它識別出來並進行處理。

r-->在運行隊列中等待的進程數
b-->在等待io的進程數
w-->可以進入運行隊列但被替換的進程
memoy
swap-->現時可用的交換記憶體(k表示)
free-->閒置記憶體(k表示)
pages
re--》回收的頁面
mf--》非嚴重錯誤的頁面
pi--》進入頁面數(k表示)
po--》出頁面數(k表示)
fr--》空餘的頁面數(k表示)
de--》提前讀入的頁面中的未命中數
sr--》通過時鐘演算法掃描的頁面
disk 顯示每秒的磁碟操作。 s表示scsi盤,0表示盤號
fault 顯示每秒的中斷數
in--》裝置中斷
sy--》系統中斷
cy--》cpu交換
cpu 表示cpu的使用狀態
cs--》使用者進程使用的時間
sy--》系統進程使用的時間
id--》cpu閒置時間
如果 r經常大於 4 ,且id經常少於40,表示cpu的負荷很重。
如果pi,po 長期不等於0,表示記憶體不足。
如果disk 經常不等於0, 且在 b中的隊列 大於3, 表示 io效能不好。

vmstat 命令(CPU)

第一個要使用的工具是 vmstat 命令,該命令可迅速提供關於各種系統資源和與之相關的效能問題的簡要資訊。vmstat 命令報告關於核心線程的統計資訊,包括處於運行和等待隊列中的、記憶體中的、頁面調度中的、磁碟中的、中斷、系統調用、環境切換和 CPU 活動的核心線程。所報告的 CPU 活動是使用者方式、系統方式、空閑時間和等待磁碟 I/O 的百分比細目分類。

注:如果使用 vmstat 命令時不帶任何選項,或者只帶有間隔時間和任意的計數參數,例如 vmstat 2 10;那麼第一行數字為自系統重新引導以來的平均值。

作為一個 CPU 監視器,vmstat 命令優於 iostat 命令,因為 vmstat 命令是滾動的,使得它的每報告一行的輸出更容易掃描,並且如果有很多磁碟串連到系統中,由此所涉及的開銷更少。下面的樣本可以協助您識別一個程式失控時或 CPU 過度密集以至於不能在一個多使用者環境中運行時的情況。

# vmstat 2
kthr memory page faults cpu
----- ----------- ------------------------ ------------ -----------
r b avm fre re pi po fr sr cy in sy cs us sy id wa
1 0 22478 1677 0 0 0 0 0 0 188 1380 157 57 32 0 10
1 0 22506 1609 0 0 0 0 0 0 214 1476 186 48 37 0 16
0 0 22498 1582 0 0 0 0 0 0 248 1470 226 55 36 0 9

2 0 22534 1465 0 0 0 0 0 0 238 903 239 77 23 0 0
2 0 22534 1445 0 0 0 0 0 0 209 1142 205 72 28 0 0
2 0 22534 1426 0 0 0 0 0 0 189 1220 212 74 26 0 0
3 0 22534 1410 0 0 0 0 0 0 255 1704 268 70 30 0 0
2 1 22557 1365 0 0 0 0 0 0 383 977 216 72 28 0 0

2 0 22541 1356 0 0 0 0 0 0 237 1418 209 63 33 0 4
1 0 22524 1350 0 0 0 0 0 0 241 1348 179 52 32 0 16
1 0 22546 1293 0 0 0 0 0 0 217 1473 180 51 35 0 14

  此輸出顯示了在一個死迴圈中將程式引入到一個繁忙的多使用者系統中所帶來的效果。頭三個報告(已刪除摘要)表明系統平衡在 50-55% 的使用者、30-35% 的系統和 10-15% 的 I/O 等待處。當迴圈程式開始運行,所有可用的 CPU 週期都被耗用。因為迴圈程式不進行 I/O,所以它可以佔有前面因為 I/O 等待而未用過的所有周期。更糟的是,這代表當一個有用進程放棄 CPU 時,始終有一個進程準備接管 CPU。因為迴圈程式的優先順序與所有其它前台進程一樣,所以當另一個進程變得可指派時它也沒必要一定得放棄 CPU。該程式運行大約 10 秒鐘(五個報告),然後由 vmstat 命令報告的活動恢複到較正常的模式。

  最佳利用是讓 CPU 在 100% 的時間中工作。這適用於單使用者系統的情況,不需要共用 CPU。總的來說,如果 us + sy 時間低於 90%,則不認為單使用者系統是 CPU 受限制的。但是,如果在一個多使用者系統中 us + sy 時間超過 80%,則進程可能要花時間在運行隊列中等待。回應時間和輸送量會受損害。

  要檢查 CPU 是否是瓶頸,考慮 vmstat 報告中的四個 cpu 列和兩個 kthr(核心線程)列。查看故障列也是值得的:

  • cpu

    在該時間間隔內使用 CPU 時間的百分比細分。cpu 列如下:

    • us

      us 列顯示了使用者方式下所花費 CPU 時間的百分比。一個 UNIX 進程可以在使用者方式下執行,也可以在系統(核心)方式下執行。當在使用者方式下時,進程在它自己的應用程式代碼中執行,不需要核心資源來進行計算、管理記憶體或設定變數。

    • sy

      sy 列詳述了 CPU 在系統方式下執行一個進程所花時間的百分比。這包括核心進程(kprocs)和其它需要訪問核心資源的進程所消耗的 CPU 資源。如果一個進程需要核心資源,它必須執行一個系統調用,並由此切換到系統方式從而使該資源可用。例如,對一個檔案的讀或寫操作需要核心資源來開啟檔案、尋找特定的位置,以及讀或寫資料,除非使用記憶體對應檔。

    • id

      id 列顯示了沒有未決本地磁碟 I/O 時 CPU 空閑或等待的時間百分比。如果沒有線程可以執行(運行隊列為空白),系統指派一個叫做 wait 的線程,也稱為 idle kproc。在一個 SMP 系統中,每個處理器都有一個 wait 線程可指派。由 ps 命令(帶有 -k 或 -g 0選項)產生的報告將它確定為 kproc 或 wait。如果 ps 報告顯示這個線程的總計時間較高,這表明存在重要的時間段,其中沒有其它線程準備在 CPU 上運行或等待執行。系統因此大部分時間空閑和等待新任務。

    • wa

      wa 列詳細顯示了暫掛本地磁碟 I/O 和 NFS 載入的磁碟的 CPU 空閑百分比。如果在 wait 運行時至少有一個未完成的磁碟 I/O,該時間就歸為 I/O 等待時間。除非進程使用異常 I/O,否則對磁碟的 I/O 請求會導致調用的進程阻塞(或睡眠),直到請求完成為止。一旦進程的 I/O 請求完成,該進程就放入運行隊列中。如果 I/O 很快完成,該進程可以使用更多的 CPU 時間。

      超過 25% 的 wa 的值可以表示磁碟子系統可能沒有被正確平衡,或者這也可能是磁碟密集工作負載的結果。

  • kthr

    每秒鐘在採樣間隔時間上對各種隊列中的核心線程數求得的平均值。kthr 列如下:

    • r

      可啟動並執行核心線程平均數,包括正在啟動並執行線程和正在等待 CPU 的線程。如果這個數字大於 CPU 的數目,至少有一個線程要等待 CPU,等待 CPU 的線程越多,越有可能對效能產生影響。

    • b

      每秒 VMM 等待隊列中的核心線程平均數。這包括正在等待檔案系統 I/O 的線程,或由於記憶體裝入控制而暫掛的線程。

      如果進程由於記憶體裝入控制而暫掛,在 vmstat 報告中的阻塞列(b)表明線程數目增加,而不是運行隊列數目增加。

    • p

      對於 vmstat -I,是每秒等待原始裝置 I/O 的線程數目。等待檔案系統 I/O的線程不包括在這裡。

  • 故障

    關於進程式控制制的資訊,如陷阱和中斷率。故障列如下:

    • in

      在某一時間間隔中觀測到的每秒裝置中斷數。

    • sy

      在某一時間間隔中觀測到的每秒系統調用次數。通過明確的系統調用,使用者進程可以使用資源。這些調用指示核心執行調用線程的操作,並在核心和該進程之 間交換資料。因為工作負載和應用程式變化很大,不同的調用執行不同的功能,所以不可能定義每秒鐘有多少系統調用才算太多。但是通常來講,在一個單一處理器系 統上當 sy 列增大到超過每秒鐘 10000 個調用時,則要求進行進一步調查(在一個 SMP 系統上,這個數字為每個處理器每秒鐘 10000 個調用)。一個原因可能是“輪詢”子常式,像 select() 子常式。對這一列,建議進行一個基準評估,給出正常 sy 值的計數。

    • cs

      在某一時間間隔中觀測到的每秒鐘環境切換次數。物理 CPU 資源細分為每個 10 毫秒的邏輯時間片。假設一個線程被調度運行,它將一直運行直到它的時間片用完、直到被搶先或直到它自願放棄 CPU 控制權。當給予另一個線程 CPU 控制權時,必須儲存前一個線程的上下文或工作環境,並且必須裝入當前線程的上下文。作業系統有一個很有效環境切換過程,所以每次切換並不耗費資源。任 何環境切換的顯著增加,如當 cs 比磁碟 I/O 和網路資訊包速率高得多,都應進行進一步調查。

 

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.