I/O 監控介紹ios
磁盤I/O 子系統是Linux 系統中最慢的部分.這個主要是歸於CPU到物理操做磁盤之間距離(譯註:盤片旋轉以及尋道).若是拿讀取磁盤和內存的時間做比較就是分鐘級到秒級,這就像7天和7分鐘的區別.所以本質上,Linux 內核就是要最低程度的下降I/O 數.本章將訴述內核在磁盤和內存之間處理數據的這個過程當中,哪些地方會產生I/O.數據庫
Linux 內核將硬盤I/O 進行分頁,多數Linux 系統的默認頁大小爲4K.讀和寫磁盤塊進出到內存都爲4K 頁大小.你可使用time 這個命令加-v 參數,來檢查你係統中設置的頁大小:api
root@vmware1:~# /usr/bin/time -v date 緩存
Major and Minor Page Faults(譯註:主要頁錯誤和次要頁錯誤)app
Linux,相似多數的UNIX 系統,使用一個虛擬內存層來映射硬件地址空間.當一個進程被啓動,內核先掃描CPU caches和物理內存.若是進程須要的數據在這2個地方都沒找到,就須要從磁盤上讀取,此時內核過程就是major pagefault(MPF).MPF 要求磁盤子系統檢索頁並緩存進RAM.dom
一旦內存頁被映射進內存的buffer cache(buff)中,內核將嘗試從內存中讀取或寫入,此時內核過程就是minor pagefault(MnPF).與在磁盤上操做相比,MnPF 經過反覆使用內存中的內存頁就大大的縮短了內核時間.ide
如下的例子,使用time 命令驗證了,當進程啓動後,MPF 和 MnPF 的變化狀況.第一次運行進程,MPF 會更多:函數
第二次再運行時,內核已經不須要進行MPF了,由於進程所需的數據已經在內存中:工具
文件緩存區就是指,內核將MPF 過程最小化,MnPF 過程最大化.隨着系統不斷的產生I/O,buffercache也將不斷的增長.直到內存不夠,以及系統須要釋放老的內存頁去給其餘用戶進程使用時,系統就會丟棄這些內存頁.結果是性能
如下例子,是查看/proc/meminfo 文件
能夠看出,這個系統總計有2GB(Memtotal)的可用內存.當前的空閒內存爲52MB (MemFree),有24 MB內存被分配磁盤寫操做(Buffers),還有1.7 GB頁用於讀磁盤(Cached).
內核這樣是經過MnPF機制,而不表明全部的頁都是來自磁盤.經過以上部分,咱們不可能確認系統是否處於瓶頸中.
Type of Memory Pages
在Linux 內核中,memory pages有3種,分別是:
1,Read Pages - 這些頁經過MPF 從磁盤中讀入,並且是隻讀.這些頁存在於Buffer Cache中以及包括不可以修改的靜態文件,二進制文件,還有庫文件.當內核須要它們時,將讀取到內存中.若是內存不足,內核將釋放它們回空閒列表中.程序再次請求時,則經過MPF 再次讀回內存.
2,Dirty Pages - 這些頁是內核在內存中已經被修改過的數據頁.當這些頁須要同步回磁盤上,由pdflush 負責寫回磁盤.若是內存不足,kswapd (與pdflush 一塊兒)將這些頁寫回到磁盤上並釋放更多的內存.
3,AnonymousPages - 這些頁屬於某個進程,可是沒有任何磁盤文件和它們有關.他們不能和同步回磁盤.若是內存不足,kswapd 將他們寫入swap 分區上並釋放更多的內存(」swapping」 pages).
應用程序有不少選擇能夠寫髒頁回磁盤上,可經過I/O 調度器使用 fsync() 或 sync() 這樣的系統函數來實現當即寫回.若是應用程序沒有調用以上函數,pdflush 進程會按期與磁盤進行同步.
#ps -ef | grep pdflush
root 186 6 0 18:04 ? 00:00:00 [pdflush]
當以爲系統中出現了I/O瓶頸時,可使用標準的監控軟件來查找緣由.這些工具包括了top,vmstat,iostat,sar.它們的輸出結果一小部分是很類似,不過每一個也都提供了各自對於性能不一樣方面的解釋.如下章節就將討論哪些狀況會致使I/O 瓶頸的出現.
每一個I/O 請求到磁盤都須要若干時間.主要是由於磁盤的盤邊必須旋轉,機頭必須尋道.磁盤的旋轉經常被稱爲」rotationaldelay」(RD),機頭的移動稱爲」disk seek」(DS).一個I/O 請求所需的時間計算就是DS加上RD.磁盤的RD 基於設備自身RPM 單位值(譯註:RPM 是Revolutions Perminute的縮寫,是轉/每分鐘,表明了硬盤的轉速).一個RD 就是一個盤片旋轉的
半圓.如何計算一個10K RPM設備的RD 值呢:
1.10000 RPM / 60 seconds (10000/60 = 166 RPS)
2.轉換爲 166分之1 的值(1/166 =0.006 seconds/Rotation)
3.單位轉換爲毫秒(6 MS/Rotation)
4.旋轉半圓的時間(6/2 = 3MS) 也就是 RD
5.加上平均3 MS 的尋道時間 (3MS + 3MS = 6MS)
6.加上2MS 的延遲(6MS + 2MS = 8MS)
7.1000 MS / 8 MS (1000/8 = 125 IOPS)
每次應用程序產生一個I/O,在10K RPM磁盤上都要花費平均 8MS.在這個固定時間裏,磁盤將盡量且有效率在進行讀寫磁盤.IOPS 能夠計算出大體的I/O 請求數,10K RPM 磁盤有能力提供120-150 次IOPS.評估IOPS 的效能,可用每秒讀寫I/O 字節數除以每秒讀寫IOPS 數得出.
per I/O產生的KB 字節數是與系統自己workload相關的,有2種不一樣workload的類型,它們是sequential和random.
iostat 命令提供信息包括IOPS 和每一個I/O 數據處理的總額.可以使用iostat-x 查看.順序的workload是同時讀順序請求大量的數據.這包括的應用,好比有商業數據庫(database)在執行大量的查詢和流媒體服務.在這個workload 中,KBper I/O 的比率應該是很高的.Sequential workload 是能夠同時很快的移動大量數據.若是每一個I/O 都節省了時間,那就意味了能帶來更多的數據處理.
評估IOPS 的效能,可用每秒讀寫I/O 字節數除以每秒讀寫IOPS 數得出,好比:
rkB/s 除以 r/s
wkB/s 除以 w/s
53040/105 =505KB per I/O
71152/102 =697KB per I/O
在上面例子可看出,每次循環下,/dev/sda 的per I/O 都在增長
Random的worklaod環境下,不依賴於數據大小的多少,更多依賴的是磁盤的IOPS 數.Web和Mail 服務就是典型的Random workload.I/O 請求內容都很小.Random workload是同時每秒會有更多的請求數產生.因此,磁盤的IOPS 數是關鍵.
計算方式和以前的公式一致:
2640/102 = 23KB per I/O
3176/130 = 24KB per I/O
(譯註:對於順序I/O來講,主要是考慮讀取大量數據的能力即KB per request.對於隨機I/O系統,更須要考慮的是IOPS值)
若是系統沒有足夠的RAM 響應全部的請求,就會使用到SWAP device.就像使用文件系統I/O,使用SWAP device 代價也很大.若是系統已經沒有物理內存可用,那就都在SWAP disk上建立不少不少的內存分頁,若是同一文件系統的數據都在嘗試訪問SWAP device,那系統將遇到I/O 瓶頸.最終致使系統性能的全面崩潰.若是內存頁不可以及時讀或寫磁盤,它們就一直保留在RAM中.若是保留時間過久,內核又必須釋放內存空間.問題來了,I/O操做都被阻塞住了,什麼都沒作就被結束了,不可避免地就出現kernel panic和system crash.
下面的vmstat 示範了一個內存不足狀況下的系統:
這個結果可看出,大量的讀請求回內存(bi),致使了空閒內存在不斷的減小(free).這就使得系統寫入swap device的塊數目(so)和swap 空間(swpd)在不斷增長.同時看到CPU WIO time(wa)百分比很大.這代表I/O 請求已經致使CPU 開始效率低下.
要看swaping 對磁盤的影響,可以使用iostat 檢查swap 分區
在這個例子中,swap device(/dev/sda1) 和file system device(/dev/sda3)在互相做用於I/O. 其中任一個會有很高寫請求(w/s),也會有很高wait time(await),或者較低的服務時間比率(svctm).這代表2個分區之間互有聯繫,互有影響.
I/O 性能監控包含了如下幾點:
1.當CPU 有等待I/O 狀況時,那說明磁盤處於超負荷狀態.
2.計算你的磁盤可以承受多大的IOPS 數.
3.肯定你的應用是屬於隨機或者順序讀取磁盤.
4.監控磁盤慢須要比較wait time(await) 和 service time(svctm).
5.監控swap 和系統分區,要確保virtualmemory不是文件系統I/O 的瓶頸.