知識星球
生產中經常遇到一些IO延時長導致的系統吞吐量下降、響應時間慢等問題，例如交換機故障、網線老化導致的丟包重傳；儲存陣列條頻寬度不足、快取不足、QoS限制、RAID級別設定不當等引起的IO延時。
一、評估 IO 能力的前提
評估一個系統IO能力的前提是需要搞清楚這個系統的IO模型是怎麼樣的。那麼IO模型是什麼，為什麼要提煉IO模型呢？
(一) IO模型
在實際的業務處理過程中，一般來說IO比較混雜，比如說讀寫比例、IO尺寸等等，都是有波動的。所以我們提煉IO模型的時候，一般是針對某一個特定的場景來建立模型，用於IO容量規劃以及問題分析。
最基本的模型包括：IOPS，頻寬和IO的大小。如果是磁碟IO，那麼還需要關註：
-
磁碟IO分別在哪些盤
-
讀IO和寫IO的比例
-
讀IO是順序的還是隨機的
-
寫IO是順序的還是隨機的
(二)為什麼要提煉IO模型
不同模型下，同一臺儲存，或者說同一個LUN，能夠提供的IOPS、頻寬（MBPS）、響應時間3大指標的最大值是不一樣的。
當儲存中提到IOPS最大能力的時候，一般採用隨機小IO進行測試，此時佔用的頻寬是非常低的，響應時間也會比順序的IO要長很多。如果將隨機小IO改為順序小IO，那麼IOPS還會更大。當測試順序大IO時，此時頻寬佔用非常高，但IOPS卻很低。
因此，做IO的容量規劃、效能調優需要分析業務的IO模型是什麼。
二、評估工具
(一)磁碟IO評估工具
磁碟IO能力的評估工具有很多，例如orion、iometer，dd、xdd、iorate，iozone，postmark，不同的工具支援的作業系統平臺有所差異，應用場景上也各具特色。
有的工具可以模擬應用場景，比如orion是oracle出品，模擬Oracle資料庫IO負載(採用與Oracle相同的IO軟體棧)。
模擬Oracle應用對檔案或磁碟分割槽進行讀寫(可指定讀寫比例、IO size，順序或隨機)這裡就需要提前知道自己的IO模型。如果不知道，可以採用自動樣式，讓orion自動的跑一遍，可以得出不同行程的併發讀寫下，最高的IOPS、MBPS，以及對應的響應時間。
比對DD，僅僅是對檔案進行讀寫，沒有模擬應用、業務、場景的效果。Postmark可以實現檔案讀寫、建立、刪除這樣的操作。適合小檔案應用場景的測試。
(二)網路IO評估工具
-
Ping：最基本的，可以指定包的大小。
-
IPerf、ttcp：測試tcp、udp協議最大的頻寬、延時、丟包。
-
衡量windows平臺下的頻寬能力，工具比較多：NTttcp、LANBench、pcattcp、LAN Speed Test (Lite)、NETIO、NetStress。
三、主要監控指標和常用監控工具
(一)磁碟IO
對於儲存IO：Unix、Linux平臺，Nmon、IOstat是比較好的工具。Nmon用於事後分析，IOstat可用於實時檢視，也可以採用指令碼記錄下來事後分析。
1. IOPS
-
總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.頻寬
-
總頻寬：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
3.響應時間
-
每個盤對應的讀響應時間：命令列iostat -Dl：read – avg serv，max serv
-
每個盤對應的寫響應時間：命令列iostat -Dl：write – avg serv，max serv
4.其他
磁碟繁忙程度、佇列深度、每秒佇列滿的次數等等。
(二)網路IO
1.頻寬
-
最好在網路裝置處直接檢視流量（比較準），如果在業務的伺服器也可以檢視
-
Nmon：NET Sheet
-
命令列topas：Network：BPS、B-In、B-Out
2.響應時間
簡單的方法，可採用ping命令檢視ping的延時是否在合理範圍，是否有丟包現象。
有些交換機對ping命令設定了較低的優先順序，可能在回覆、轉發ping包的時候有延遲，因此ping的結果不一定能反映真實情況。如果需要更為精確的測量可以探針捕獲從某伺服器建立TCP連線時傳送的SYN包後開始計時起，到其收到對端發回的TCP SYNACK後的時間差。
更為準確、利於後期分析的方法是採用專業的網路裝置在網路裝置的埠處進行報文捕獲和計算分析。
四、效能定位與最佳化
(一)對磁碟IO爭用的調優思路有哪些？
典型問題：針對主要爭用是IO相關的場景下，調優的思路有哪些？主要的技術或者方法是什麼？
一、首先要搞清楚IO爭用是因為應用等層面的IO量過大導致，還是系統層面不能承載這些IO量。
如果應用層面有過多不必要的讀寫，首先解決應用問題。
舉例1：資料庫裡面用於sort的buffer過小，當做sort的時候，有大量的記憶體與磁碟之間的資料交換，那麼這類IO可以透過擴大sort buffer的記憶體來減少或避免。
舉例2：從應用的角度，一些日誌根本不重要，不需要寫，那麼可以把日誌級別調低、甚至不記錄日誌，資料庫層面可以加hint “no logging”。
二、儲存問題的分析思路
儲存IO問題可能出現在IO鏈路的各個環節，分析IO瓶頸是主機/網路/儲存中的哪個環節導致的。
IO從應用->記憶體快取->塊裝置層->HBA卡->驅動->交換網路->儲存前端->儲存cache->RAID組->磁碟，經過了一個很長的鏈條，分析思路：
-
1、主機側：應用->記憶體快取->塊裝置層→HBA卡->驅動
-
2、網路側：交換網路
-
3、儲存側：儲存前端->儲存cache->RAID組->磁碟
1、主機側
當主機側觀察到的時延很大，儲存側的時延較小，則可能是主機側或網路存在問題。
主機是I/O的發起端，I/O特性首先由主機的業務軟體和作業系統軟體和硬體配置等決定。例如，在“服務佇列滿”這一章節介紹的I/O 佇列長度引數(queue_depth)，當然，還有許多其他的引數(如： Driver 可以向儲存發的最大的 I/O、光纖卡DMA Memor區域大小、塊裝置併發數、HBA卡併發數)。
若排查完成，效能問題還是存在，則需要對組網及鏈路、儲存側進行效能問題排查。
2、網路側
當主機側觀察到的時延很大，儲存側的時延較小，且排查主機側無問題時，則效能問題可能出現在鏈路上。
可能的問題有：頻寬達到瓶頸、交換機配置不當、交換機故障、多路徑選路錯誤、線路的電磁幹擾、光纖線有損、介面鬆動等。頻寬達到瓶頸、交換機配置不當、多路徑選路錯誤、線路的電磁幹擾等。
3、儲存側
如果主機側時延與儲存側時延都很大且相差較小，說明問題可能出現在儲存上。首先需要瞭解當前儲存側所承載的IO模型、儲存資源配置，並從儲存側收集效能資料，按照I/O路徑進行效能問題的定位。
常見原因如硬碟效能達到上限、映象頻寬達到上限、儲存規劃(如條帶過小)、硬碟域和儲存池劃分（例如劃分了低速的磁碟）、thin LUN還是thick LUN、LUN對應的儲存的快取設定(快取大小、快取型別，記憶體還是SSD)。
IO的Qos限制的磁碟IO的頻寬、LUN優先順序設定、儲存介面模組數量過小、RAID劃分(比如RAID10 > RAID5 > RAID6)、條頻寬度、條帶深度、配置快照、克隆、遠端複製等增值功能拖慢了效能、是否有重構、Balancing等操作正在進行、儲存控制器的CPU利用率過高、LUN未格式化完成引起短時的效能問題、cache刷入磁碟的引數(高低水位設定)，甚至資料在碟片的中心還是邊緣等等。
具體每個環節 都有一些具體的方法、命令、工具來檢視效能表現，這裡不再贅述。
(二)關於低延遲事務、高速交易的應用在IO方面可以有哪些調優思路和建議？
典型問題：關於近期在一些證券行業碰到的低延遲事務、高速交易的應用需求，在IO模型路徑方面可以有哪些可以調優的思路和建議？
對於低延遲事務，可以分析一下業務是否有持久化儲存日誌的需要，或者說儲存的安全程度有多高，以此來決定採用什麼樣的IO。
1.從業務角度
比如說業務上不需要儲存日誌，那就不用寫IO。或者儲存級別不高，那就可以只寫一份資料，對於儲存級別較高的日誌，一般要雙寫、或多寫。
2.從儲存介質角度
-
1）可以全部採用SSD
-
2）或者採用SSD作為儲存的二級快取(一級快取是記憶體）
-
3）或者儲存伺服器裡面採用儲存分級(將熱點資料遷移到SSD、SAS等效能較好的硬碟上）
-
4）可以採用RAMDISK（記憶體作為磁碟用）
-
5）增加LUN所對應的儲存伺服器的快取
3.從配置的角度
普通磁碟儲存的LUN，可以設定合理的RAID樣式（比如RAID10）去適應你的業務場景。
分條的深度大於等於一個IO的大小、有足夠的寬度支援併發寫。
4.IO路徑的角度
採用高速的組網技術，而不用iSCSI之類的低速方式。
(三) 網路IO問題定位思路和方法
與磁碟IO類似，網路IO同樣需要分段查詢和分析。透過網路抓包和分析的工具，診斷網路的延時、丟包等異常情況出現在哪一段，然後具體分析。
同時，抓主機端的IPtrace有助診斷不少的網路問題，參考文章http://www.aixchina.net/Article/177921
(四)誤判為IO問題的案例
很多時候，應用響應時間很慢，看似是IO問題，實則不然，這裡舉兩個例子。
1.案例分享：
Oracle buffer等待佔總時間的大頭，在一個場景中，Oracle的awr報告top10事件的第一名是：buffer busy waits。
buffer busy waits是個比較general的等待，是session等待某個buffer引起的，但具體是什麼buffer並不清楚，比如log sync等待也會引起buffer busy wait。
這是個連帶指標，分析是暫且不管，需要看看他臨近的問題事件是什麼。
awr報告top10事件的第二名是enq：TX – index contention。這裡的臨近事件就是enq：TX – index contention， index contention常由大量併發INSERT 造成的 index split 引起，也就是說不斷更新索引的過程中，二叉樹不斷長大。需要分裂，分裂的時候，其他Session就需要等著(這裡的分析需要些資料庫知識)。
之後的調優過程中，將索引分割槽，避免競爭。調整後重新測試，Index contention、Bufferbusy wait雙雙從top10事件中消失了。
這類資料庫相關的等待事件非常常見，看似是等待IO，實際上是資料庫的規劃設計有問題。
2.案例分享：
Ping延時間歇性暴增。某業務系統的響應時間很不穩定，該系統有兩類伺服器構成，可以簡單理解為A和B，A為客戶端，B為服務端，A處業務的響應時間非常不穩定。
第一步：從各類資源(CPU、記憶體、網路IO、磁碟IO)中追查原因。最終發現A與B直接的網路延時非常不穩定。A ping B，在區域網環境，按理說延時應該是0ms-1ms之間，而我們在業務高峰時發現，隔一小段時間就有100-200ms的延時出現。即使在沒有業務的情況下，Ping也30-40ms的延時。
第二步：開始排查網路。換A的物理埠、換交換機、換網線、換對端的物理埠等等一系列措施之後，發現問題依然存在。
第三步：採用網路探測裝置，從交換機兩側埠抓包，分析一個tcp連線的建立過程時間消耗在哪裡。分析後發現，200ms的延時，都是在B測。即一個tcp連線建立過程在A側和交換機側幾乎沒有什麼時間消耗。
第四步：B側多臺分割槽共用一個物理機。猜測是否是分割槽過多導致。當只有一個LPAR啟動的時候，沒有ping的延時，當啟動一部分LPAR時候，延時較小，當所有LPAR均啟動，Ping 延時較大。
問題根本原因：此時，問題水落石出，原來是由於分割槽過多導致了B回覆A的ping有了延時。那麼為什麼會出現這種情況呢？一個物理機上CPU資源是有限的（本環境中是3顆），即使只有一個LPAR，其上面的N個行程也會去輪流使用CPU，何況此時是M臺LPAR，MN個行程去輪流使用這三個CPU，當然排程演演算法並不是這麼簡單，這裡僅僅是從理論上做個說明。
假設每個CPU時間片是10ms，那麼極端情況下，一個行程要等到CPU需要等待(MN-1)*10(ms)/3。況且，這麼多LPAR的行程輪詢一遍CPU，CPU裡面的cache 資料估計早就被擠走了，重新載入是比較耗時的。
應對方法：之前LPAR也設定了保障的CPU(MIPS數量的保障)，但只有數量沒有質量(上述提到的CPU cache問題，即親和性問題)。
將重要的LPAR分配dedicated CPU，保證CPU資源的質量，保證輪詢CPU的客戶儘量少，這樣CPU cache中的資料儘量不被清走。經驗證，Ping延時基本消失，方法有效。本案例是一起看似是網路問題，但實際是資源排程方式的問題。
順便提一句，很多情況下，客戶端的響應時間不穩定都是由伺服器端的服務能力不穩定造成的。一般情況下都是應用、資料庫的問題造成。而本案例是作業系統層面答覆Ping出現間歇性延時，很容易誤導我們的分析判斷。
更多關於效能、IO調優和技術分析內容，請參閱整理的“IO知識和系統效能深度調優全解(第2版)”電子書(透過第2版發貨)，點選“原文連結”瞭解內容詳情。
溫馨提示：
請搜尋“ICT_Architect”或“掃一掃”二維碼關註公眾號，點選原文連結獲取電子書詳情。
求知若渴, 虛心若愚
