[[249884]]

 對于業務服務器的用戶來說，看到的是文件系統或裸設備，從文件系統到物理磁盤大概是下圖的樣子。

業務服務器的操作系統作為存儲的用戶只能看到disk(存儲層面的LUN)，而存儲管理員才知道存儲內部的具體RAID方式、條帶化方式等等，在關注系統性能的活動(性能測試、性能調優)中，一般很少直接關注磁盤IO的指標，而是遇到性能問題(比如業務的響應時間非常慢)，并且逐步排查到磁盤時，才重點關注磁盤IO的性能指標。這是因為，磁盤IO的性能的確是不好拿一個指標說清楚的事。

當磁盤IO有性能問題，需要分析IOPS、MBPS、服務時間、平均每次寫入的block大小、隊列等待時間等指標，分析IO路徑、驅動、光纖卡、光纖交換機、后臺存儲的規劃、硬盤域和存儲池劃分、thin LUN還是thick LUN、存儲的緩存設置、IO的Qos、磁盤類型、存儲接口模塊數量、RAID劃分、是否配置快照、克隆、遠程復制等增值功能、存儲控制器的CPU利用率，甚至數據在盤片的中心還是邊緣等等。

本節并不主要從存儲的角度介紹，而是從存儲的用戶(業務服務器的操作系統)的角度介紹磁盤IO的性能指標，以及相關分析。

主要關注指標

雖然每類物理資源都有N個性能指標來體現，但CPU、內存資源最主要的指標只有一個，即利用率，但磁盤IO的主要指標卻有三個(IOPS、帶寬、響應時間)。這是因為存儲的能力會根據IO模型的不同而差異較大，IO模型可以理解為讀IO和寫IO的比例、順序的還是隨機的、每個IO的大小等等。例如：當測試IOPS最大能力的時候，采用隨機小IO進行測試，此時占用的帶寬是非常低的，響應時間也會比順序的IO要長很多。而測試順序大IO時，此時帶寬占用非常高，但IOPS卻很低。

從業務服務器、存儲控制器、前端主機端口、磁盤、LUN、存儲池等角度，都有以下三個主要指標，本文重點從業務服務器角度介紹。

IOPS

I/O per second，即每秒鐘可以處理的I/O個數，用來衡量存儲系統的I/O處理能力。在數據庫OLTP(Online Transaction Processing)業務場景，通常以IOPS衡量系統的性能。測量存儲的最大IOPS往往是以隨機讀寫小IO來評估。

1. 獲取來源

總IOPS：Nmon DISK_SUMM Sheet：IO/Sec

每個盤對應的讀IOPS ：Nmon DISKRIO Sheet

每個盤對應的寫IOPS ：Nmon DISKWIO Sheet

總IOPS：命令行iostat -Dl：tps

每個盤對應的讀IOPS ：命令行iostat -Dl：rps

每個盤對應的寫IOPS ：命令行iostat -Dl：wps

2. 適用場景

對于I/O小于64KB的應用場景，存儲性能主要關注IOPS指標。

OLTP(聯機事務處理)系統是大量用戶在線進行事務操作的數據庫業務的一種應用類型。

OLTP應用的負載特征如下：

從數據庫角度看：

– 每個事務的讀、寫、更改涉及的數據量非常小。

– 數據庫的數據必須是最新的，所以對數據庫的可用性要求很高。

– 同時有很多用戶訪問。

– 要求數據庫快速響應，通常一個事務需要在幾秒內完成。

從存儲角度看：

– 每個I/O非常小，通常為2KB～8KB。

– 訪問硬盤數據的位置非常隨機。

– 至少30%的數據是隨機寫操作。

– REDO日志(重做日志文件)寫入非常頻繁

帶寬

每秒鐘可以處理的數據量，常以KB/S或MB/s或GB/s為單位，表示為KBPS/MBPS/GBPS，用于衡量存儲系統的吞吐量。在數據庫OLAP(Online Analytical Processing)業務、媒資業務、視頻監控業務等應用場景，通常以帶寬衡量系統性能。

1. 獲取來源

總帶寬：Nmon DISK_SUMM Sheet：Disk Read KB/s，Disk Write KB/s

每個盤對應的讀帶寬：Nmon DISKREAD Sheet

每個盤對應的寫帶寬：Nmon DISKWRITE Sheet

總帶寬：命令行iostat -Dl：bps

每個盤對應的讀帶寬：命令行iostat -Dl：bread

每個盤對應的寫帶寬：命令行iostat -Dl：bwrtn

2. 適用場景

對于I/O大于等于64KB的應用場景，存儲性能主要關注帶寬指標。

OLAP業務是用戶長時間在線對數據庫執行復雜的統計查詢操作的一種應用類型。

OLAP應用的負載特征如下：

從數據庫管理員角度看：

– 數據修改量小或無數據修改。

– 數據查詢過程復雜。

– 數據的使用頻率逐漸減小。

– 查詢結果以統計值呈現，方便查看。

從存儲采樣看：

– 單個I/O數據量大，通常為64KB～1MB。

– 讀取操作通常順序讀取。

– 當進行讀取操作進行時，寫操作的數據存放在臨時表空間內。

– 對在線日志寫入少。只有在批量加載數據時，寫入操作增多。

響應時間

也稱為時延或者服務時間，發起I/O請求到I/O處理完成的時間間隔，常以毫秒(ms)為單位。

1. 獲取來源

每個盤對應的讀響應時間：命令行iostat -Dl：read - avg serv，max serv

每個盤對應的寫響應時間：命令行iostat -Dl：write - avg serv，max serv

2. 最佳實踐

數據庫OLTP業務一般時延要求10ms以下，事實上大多數情況下不足1ms;VDI(Virtual Desktop Infrastructure)場景一般時延要求30ms以下;視頻點播和視頻監控的時延要求隨碼率的不同而不同。

從業務系統用戶的角度，響應時間是這三個指標中最重要的指標。因為，如果IOPS或帶寬達到了存儲的瓶頸，那么一定會體現在IO響應時間上。

其他關注指標

用戶從業務系統經常關注的其他指標有：磁盤繁忙程度、隊列滿等等，這里簡單介紹一下。

磁盤繁忙程度

Diskbusy體現了磁盤驅動的利用率，即磁盤驅動有百分之多少時間是活動的。

1. 獲取來源

Nmon DISKBUSY Sheet

命令行iostat -Dl：% tm_act

2. 詳細解釋

但這個指標的高低與IOPS、帶寬并不是線性關系。例如當diskbusy=80%的時候IOPS=500，當diskbusy=90%的時候IOPS可能可以達到800。

可以把驅動理解為道路，每個IO的數據塊理解為道路上行使的汽車。當道路上沒有車的時候，認為是不活動的;當道路上有車的時候，認為是活動的，但有1輛車也是活動，有10輛車也是活動。因此diskbusy并不能作為磁盤IO的重要性能指標。但在日常情況下，可以從這個值的高低對磁盤使用情況有個大概的判斷。

服務隊列滿

服務隊列每秒變滿(磁盤不再接受服務請求)的次數。

1. 獲取來源

命令行iostat -Dl：sqfull

2. 詳細解釋

通常情況下這個sqfull的值為0，如果經常不為0，可能是IO隊列深度太小或者磁盤/存儲能力不足。

queue_depth 是IO隊列深度，即AIX 一次可以傳送到磁盤設備的命令的數量，把命令放在隊列中再傳送給磁盤可以提高 I/O 性能。這個屬性限制了 AIX 可以傳送到設備的最大命令的數量。可以通過命令查看lsattr -El hdiskxxx|grep queue_depth，queue_depth 默認數值為 4，可以調整。但調整queue_depth這種方法對于提高磁盤IO能力來說很有限。

文件系統使用率

文件系統和inode的利用率其實已經不在磁盤IO的討論范圍，但仍然屬于磁盤的范圍，需要業務系統用戶關注。

1. 獲取來源

NMON：JFSFILE SHEET

命令行df- g

2. 最佳實踐

當使用率超過80%的時候，系統的性能可能會被拖慢。

同時，統計業務量與文件系統利用率的增長情況，可以推測該文件系統可以支撐的最大業務量，管理員可以根據日常業務量和文件系統的空間，設定備份刪除策略。

Inode使用率

Inode：索引節點，它用來存放文件及目錄的基本信息，inode數量即文件系統的節點的最大數量。

Inode使用率容易被忽略。對于一些文件大小很小，文件數量卻很大的系統，若采用默認參數生成文件系統，可能導致inode數量不足。當inode使用率達到100%后就不能再創建新的文件或目錄。

1. 獲取來源

NMON：JFSINODE SHEET

命令行df- g：%Iused