磁盤 IO 和網(wǎng)絡 IO 該如何評估、監(jiān)控、性能定位和優(yōu)化

磁盤 IO 和網(wǎng)絡 IO 該如何評估、監(jiān)控、性能定位和優(yōu)化

生產(chǎn)中經(jīng)常遇到一些IO延時長導致的系統(tǒng)吞吐量下降、響應時間慢等問題，例如交換機故障、網(wǎng)線老化導致的丟包重傳；存儲陣列條帶寬度不足、緩存不足、QoS限制、RAID級別設置不當?shù)纫鸬腎O延時。

一、評估 IO 能力的前提

評估一個系統(tǒng)IO能力的前提是需要搞清楚這個系統(tǒng)的IO模型是怎么樣的。那么IO模型是什么，為什么要提煉IO模型呢？

（一）、IO模型

在實際的業(yè)務處理過程中，一般來說IO比較混雜，比如說讀寫比例、IO尺寸等等，都是有波動的。所以我們提煉IO模型的時候，一般是針對某一個特定的場景來建立模型，用于IO容量規(guī)劃以及問題分析。

最基本的模型包括：

• IOPS
• 帶寬
• IO的尺寸（大?。?/li>

如果是磁盤IO，那么還需要關注：

• 磁盤IO分別在哪些盤
• 讀IO和寫IO的比例
• 讀IO是順序的還是隨機的
• 寫IO是順序的還是隨機的

（二）、為什么要提煉IO模型

不同模型下，同一臺存儲，或者說同一個LUN，能夠提供的IOPS、帶寬（MBPS）、響應時間3大指標的最大值是不一樣的。

當存儲中提到IOPS最大能力的時候，一般采用隨機小IO進行測試，此時占用的帶寬是非常低的，響應時間也會比順序的IO要長很多。如果將隨機小IO改為順序小IO，那么IOPS還會更大。當測試順序大IO時，此時帶寬占用非常高，但IOPS卻很低。

因此，做IO的容量規(guī)劃、性能調優(yōu)需要分析業(yè)務的IO模型是什么。

二、評估工具

（一）、磁盤IO評估工具

磁盤IO能力的評估工具有很多，例如orion、iometer，dd、xdd、iorate，iozone，postmark，不同的工具支持的操作系統(tǒng)平臺有所差異，應用場景上也各具特色。

有的工具可以模擬應用場景，比如orion是oracle出品，模擬Oracle數(shù)據(jù)庫IO負載（采用與Oracle相同的IO軟件棧）。

即模擬oracle應用對文件或磁盤分區(qū)進行讀寫（可指定讀寫比例、io size，順序or隨機）這里就需要提前知道自己的IO模型。如果不知道，可以采用自動模式，讓orion自動的跑一遍，可以得出不同進程的并發(fā)讀寫下，最高的IOPS、MBPS，以及對應的響應時間。

比對dd，僅僅是對文件進行讀寫，沒有模擬應用、業(yè)務、場景的效果。

postmark可以實現(xiàn)文件讀寫、創(chuàng)建、刪除這樣的操作。適合小文件應用場景的測試。

（二）、網(wǎng)絡IO評估工具

ping：最基本的，可以指定包的大小。

iperf、ttcp：測試tcp、udp協(xié)議最大的帶寬、延時、丟包。

衡量windows平臺下的帶寬能力，工具比較多：NTttcp、LANBench、pcattcp、LAN Speed Test (Lite)、NETIO、NetStress。

三、主要監(jiān)控指標和常用監(jiān)控工具

（一）、磁盤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.其他

磁盤繁忙程度、隊列深度、每秒隊列滿的次數(shù)等等。

（二）、網(wǎng)絡IO

1.帶寬

最好在網(wǎng)絡設備處直接查看流量（比較準），如果在業(yè)務的服務器也可以查看

Nmon：NET Sheet

命令行topas：Network：BPS、B-In、B-Out

2.響應時間

簡單的方法，可采用ping命令查看ping的延時是否在合理范圍，是否有丟包現(xiàn)象。

有些交換機對ping命令設置了較低的優(yōu)先級，可能在回復、轉發(fā)ping包的時候有延遲，因此ping的結果不一定能反映真實情況。如果需要更為精確的測量可以探針捕獲從某服務器建立TCP連接時發(fā)送的SYN包后開始計時起，到其收到對端發(fā)回的TCP SYNACK后的時間差。

更為準確、利于后期分析的方法是采用專業(yè)的網(wǎng)絡設備在網(wǎng)絡設備的端口處進行報文捕獲和計算分析。

四、性能定位與優(yōu)化

（一）、對磁盤IO爭用的調優(yōu)思路有哪些？

典型問題：針對主要爭用是IO相關的場景下，調優(yōu)的思路有哪些？主要的技術或者方法是什么？

一、首先要搞清楚IO爭用是因為應用等層面的IO量過大導致，還是系統(tǒng)層面不能承載這些IO量。

如果應用層面有過多不必要的讀寫，首先解決應用問題。

舉例1:數(shù)據(jù)庫里面用于sort的buffer過小，當做sort的時候，有大量的內(nèi)存與磁盤之間的數(shù)據(jù)交換，那么這類IO可以通過擴大sort buffer的內(nèi)存來減少或避免。

舉例2：從應用的角度，一些日志根本不重要，不需要寫，那么可以把日志級別調低、甚至不記錄日志，數(shù)據(jù)庫層面可以加hint “no logging”。

二、存儲問題的分析思路

存儲IO問題可能出現(xiàn)在IO鏈路的各個環(huán)節(jié)，分析IO瓶頸是主機/網(wǎng)絡/存儲中的哪個環(huán)節(jié)導致的。

IO從應用->內(nèi)存緩存->塊設備層->HBA卡->驅動->交換網(wǎng)絡->存儲前端->存儲cache->RAID組->磁盤，經(jīng)過了一個很長的鏈條。

需要逐段分析：

1、主機側：應用->內(nèi)存緩存->塊設備層→HBA卡->驅動

2、網(wǎng)絡側：交換網(wǎng)絡

3、存儲側：存儲前端-》存儲cache-》RAID組-》磁盤

分析思路：

1、主機側

當主機側觀察到的時延很大，存儲側的時延較小，則可能是主機側或網(wǎng)絡存在問題。

主機是I/O的發(fā)起端，I/O特性首先由主機的業(yè)務軟件和操作系統(tǒng)軟件和硬件配置等決定。例如，在“服務隊列滿”這一章節(jié)介紹的I/O 隊列長度參數(shù)（queue_depth），當然，還有許多其他的參數(shù)（如： driver 可以向存儲發(fā)的最大的 I/O、光纖卡DMA memor區(qū)域大小、塊設備并發(fā)數(shù)、HBA卡并發(fā)數(shù)）。

若排查完成，性能問題還是存在，則需要對組網(wǎng)及鏈路、存儲側進行性能問題排查。

2、網(wǎng)絡側

當主機側觀察到的時延很大，存儲側的時延較小，且排查主機側無問題時，則性能問題可能出現(xiàn)在鏈路上。

可能的問題有：帶寬達到瓶頸、交換機配置不當、交換機故障、多路徑選路錯誤、線路的電磁干擾、光纖線有損、接口松動等。帶寬達到瓶頸、交換機配置不當、多路徑選路錯誤、線路的電磁干擾等。

3、存儲側

如果主機側時延與存儲側時延都很大且相差較小，說明問題可能出現(xiàn)在存儲上。首先需要了解當前存儲側所承載的IO模型、存儲資源配置，并從存儲側收集性能數(shù)據(jù)，按照I/O路徑進行性能問題的定位。

常見原因如硬盤性能達到上限、鏡像帶寬達到上限、存儲規(guī)劃（如條帶過?。?、硬盤域和存儲池劃分（例如劃分了低速的磁盤）、thin LUN還是thick LUN、LUN對應的存儲的緩存設置（緩存大小、緩存類型，內(nèi)存還是SSD）；

IO的Qos限制的磁盤IO的帶寬、LUN優(yōu)先級設置、存儲接口模塊數(shù)量過小、RAID劃分（比如RAID10>RAID5>RAID6）、條帶寬度、條帶深度、配置快照、克隆、遠程復制等增值功能拖慢了性能、是否有重構、balancing等操作正在進行、存儲控制器的CPU利用率過高、LUN未格式化完成引起短時的性能問題、cache刷入磁盤的參數(shù)（高低水位設置），甚至數(shù)據(jù)在盤片的中心還是邊緣等等。

具體每個環(huán)節(jié) 都有一些具體的方法、命令、工具來查看性能表現(xiàn)，這里不再贅述。

（二）、關于低延遲事務、高速交易的應用在IO方面可以有哪些調優(yōu)思路和建議？

典型問題：關于近期在一些證券行業(yè)碰到的低延遲事務、高速交易的應用需求，在IO模型路徑方面可以有哪些可以調優(yōu)的思路和建議？

對于低延遲事務，可以分析一下業(yè)務是否有持久化保存日志的需要，或者說保存的安全程度有多高，以此來決定采用什么樣的IO。

1.從業(yè)務角度

比如說業(yè)務上不需要保存日志，那就不用寫IO。

或者保存級別不高，那就可以只寫一份數(shù)據(jù)，對于保存級別較高的日志，一般要雙寫、或多寫。

2.從存儲介質角度

1）可以全部采用SSD

2）或者采用SSD作為存儲的二級緩存（一級緩存是內(nèi)存）

3）或者存儲服務器里面采用存儲分級（將熱點數(shù)據(jù)遷移到SSD、SAS等性能較好的硬盤上）

4）可以采用RAMDISK（內(nèi)存作為磁盤用）

5）增加LUN所對應的存儲服務器的緩存

3.從配置的角度

普通磁盤存儲的LUN，可以設置合理的RAID模式（比如RAID10）去適應你的業(yè)務場景。

分條的深度大于等于一個IO的大小、有足夠的寬度支持并發(fā)寫。

4.IO路徑的角度

采用高速的組網(wǎng)技術，而不用iSCSI之類的低速方式。

（三）、網(wǎng)絡IO問題定位思路和方法

與磁盤IO類似，網(wǎng)絡IO同樣需要分段查找和分析。通過網(wǎng)絡抓包和分析的工具，診斷網(wǎng)絡的延時、丟包等異常情況出現(xiàn)在哪一段，然后具體分析。

同時，抓主機端的IPtrace可以幫助診斷不少的網(wǎng)絡問題

性能指標之資源指標-網(wǎng)絡IO--初步診斷-trace查看

字數(shù) 2817閱讀 4748評論 0贊 1

如果從應用層面或者ping等手段定位到網(wǎng)絡有延時、抖動、丟包、中斷等異常情況時，需要進行深入的診斷分析。

此時最好的方法是采用專業(yè)的網(wǎng)絡抓包設備進行網(wǎng)絡包捕獲，并采用該廠商相應的工具進行分析診斷。不但不影響服務器本身的性能，并且可以比較快速地得出一些診斷結論。目前市場上這方面的廠商和工具也比較多。

然而本節(jié)將介紹另一種初步分析問題的手段-iptrace。通過在業(yè)務系統(tǒng)上監(jiān)控iptrace日志，之后通過wireshark工具進行分析，即可對問題有個大致的判斷。

1、iptrace抓取

舉例說明

開啟監(jiān)控：startsrc -s iptrace "-a -s 目標機IP -b -S 1500 -L 1073741824 /var/trace/iptrace.out"

該命令的含義是：iptrace記錄本機與目標機雙向傳輸?shù)男畔?，抓取的?shù)據(jù)包最大限制為1500字節(jié)，日志記錄最大為1073741824字節(jié)（1G大?。?。

關閉監(jiān)控：stopsrc -s iptrace

2、Wireshark簡介

Wireshark是windows平臺用于查看網(wǎng)口數(shù)據(jù)包的工具。核心功能是快速篩選自己需要的信息然后快速定位問題。使用Wireshark打開iptrace.out文件如下圖：

No --- 截獲的網(wǎng)絡包序號

Time --- 時間

Source --- 數(shù)據(jù)源IP

Destination --- 目標IP

Length --- 消息包總字節(jié)長度

Protocol --- 消息包協(xié)議類型

Info --- 消息包相關基本信息

以下是對應的OSI七層模型

Frame：物理層的數(shù)據(jù)幀概況

Ethernet II：數(shù)據(jù)鏈路層以太網(wǎng)幀頭部信息

Internet Protocol Version 4：互聯(lián)網(wǎng)層IP包頭部信息

Transmission Control Protocol：傳輸層TCP的數(shù)據(jù)段頭部信息

WebSphere MQ：應用層的信息，此處是MQ

常用篩選命令

可以按照需求篩選顯示網(wǎng)絡包列表，常用篩選條件如下：

1 按消息包長度篩選frame.len== （Length的值）

2 按數(shù)據(jù)源ip 篩選 ip.src eq 10.x.x.x

3 同時篩選源IP 以及協(xié)議類型ip.src eq 10.x.x.x && mq

4 按需求的協(xié)議類型篩選 mq && tcp

3、分析實例

打開iptrace文件后，首先查看右側標黑色的部分，這是wireshark認為有問題的網(wǎng)絡傳輸。

以作者實踐當中的一個例子，系統(tǒng)環(huán)境當中網(wǎng)絡延時非常不穩(wěn)定，抓取iptrace用wireshark打開之后，發(fā)現(xiàn)大量的黑色條帶，幾乎找不到不出錯的時間段。

這其中的問題五花八門，例如有：

1. 大量的tcp keep-alive ack/ tcp keep-alive
2. 大量下一個回復包的SEQ值不等于ACK
3. RST ACK
4. 大量Retransmission
5. Previous segment uncaptured
6. ACKed Unseen segment
7. 大量Dup ack
8. Destination unreachable

在幾分鐘的trace當中竟然有這么多問題，也是醉了。

3.1 大量的tcp keep-alive / tcp keep-alive ack

幾乎10個數(shù)據(jù)包里面就有2個tcp keep-alive / tcp keep-alive ack的數(shù)據(jù)包，大量占用網(wǎng)絡帶寬

首先，服務器的keep alive相關參數(shù)設置略有問題

no -a| grep tcp

tcp_keepcnt = 8

tcp_keepidle = 20

tcp_keepinit = 50

tcp_keepintvl = 2

這些參數(shù)的含義是：如果tcp連接有10秒鐘空閑，沒有報文傳輸（tcp_keepidle = 20，單位是0.5秒），那么開始發(fā)送探測（tcp alive），如果探測不成功，則后續(xù)每1秒發(fā)送一次 （tcp_keepintvl = 2），如果連續(xù)發(fā)送8次，對方?jīng)]反應，把這個tcp連接關了。

這個探測比默認值來講的確有些頻繁，但試想，如果探測一次成功了的話，后續(xù)就不需要探測了。為什么有這么多的探測呢？

3.2 大量下一個回復包的SEQ值不等于ACK

正常情況下回復的seq數(shù)值=等于上一條請求的ACK數(shù)值，而trace中看到幾乎所有keep alive的確認包（ACK）中的SEQ值=keep alive發(fā)起方的ACK+1。即每次探測后，對方的回復都不是期望的結果，因此后續(xù)不停的繼續(xù)探測，導致了大量的keep alive包。

Seq和Ack兩個字段是TCP可靠傳輸服務的關鍵部分，Seq是網(wǎng)絡包序列號(TCP把數(shù)據(jù)看成是有序的字節(jié)流，TCP隱式地對數(shù)據(jù)流的每個字節(jié)進行編號)。Ack是期望得到的下一個回復包的序列號（即Seq值）。

3.3 RST ACK

RST可能是B發(fā)的太多，A告訴B 不要發(fā)包，直到A再次通知B可以發(fā)包。 或者是A關閉異常連接，清空緩存。

由于只發(fā)現(xiàn)一條RST ACK，因此并未深入分析。

3.4 大量Retransmission重傳

重傳意味著網(wǎng)絡質量不佳，可能的原因有擁堵、目標機回復延遲、網(wǎng)絡設備丟包、網(wǎng)線質量不佳、接口松動、電磁干擾等。

3.5 Previous segment uncaptured

先前片段未能捕獲，當前收到報文的序列號值高于該連接的下一個期望序列號值時，表明之前的一個或多個網(wǎng)絡包未捕獲到。Previous segment uncaptured在正常通訊過程中也經(jīng)常出現(xiàn)，且出現(xiàn)次數(shù)不多，因此并未深入分析。

3.6 ACKed Unseen segment

Tcp ACKed unseen segment 網(wǎng)絡包回復的先前片段未截獲到，與Tcp Previoud segment not captured先前片段未能捕獲，問題相似。由于Previous segment uncaptured在正常通訊過程中也經(jīng)常出現(xiàn)，且出現(xiàn)次數(shù)不多，因此并未深入分析。

3.7 大量Dup ack

Dup ACK是沒有收到對方的應答（ACK），需要對方重復應答，3次以上的Dup ACK會造成重傳和傳輸降速。后分析發(fā)現(xiàn)，系統(tǒng)環(huán)境中對方服務器發(fā)送出來的數(shù)據(jù)包在核心交換大機側的接口處就有大量亂序。

3.8 Destination unreachable

目標不可達。由于只出現(xiàn)一次這個報錯，因此并未深入分析

綜上，從iptrace的結果中可以看到表現(xiàn)出來的問題很多，但經(jīng)過初步分析，主要問題歸結起來是1）對端回復的TCP包的SEQ值不是預期值，2）網(wǎng)絡質量不佳。下一步就需要研究出問題的對端節(jié)點以及采用網(wǎng)絡抓包設備判斷哪一段網(wǎng)絡質量不佳。

（四）、誤判為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常由大量并發(fā)INSERT 造成的 index split 引起，也就是說不斷更新索引的過程中，二叉樹不斷長大。需要分裂，分裂的時候，其他session就需要等著。（這里的分析需要些數(shù)據(jù)庫知識）

之后的調優(yōu)過程中，將索引分區(qū)，避免競爭。調整后重新測試，Index contention、Bufferbusy wait雙雙從top10事件中消失了

這類數(shù)據(jù)庫相關的等待事件非常常見，看似是等待IO，實際上是數(shù)據(jù)庫的規(guī)劃設計有問題。

2.【案例分享】：ping延時間歇性暴增

某業(yè)務系統(tǒng)的響應時間很不穩(wěn)定，該系統(tǒng)有兩類服務器構成，可以簡單理解為A和B，A為客戶端，B為服務端，A處業(yè)務的響應時間非常不穩(wěn)定。

第一步：

從各類資源（CPU、內(nèi)存、網(wǎng)絡IO、磁盤IO）中追查原因。最終發(fā)現(xiàn)A與B直接的網(wǎng)絡延時非常不穩(wěn)定。A ping B，在局域網(wǎng)環(huán)境，按理說延時應該是0ms-1ms之間，而我們在業(yè)務高峰時發(fā)現(xiàn)，隔一小段時間就有100-200ms的延時出現(xiàn)。即使在沒有業(yè)務的情況下，ping也30-40ms的延時。

第二步：

那么好，著手定位網(wǎng)絡問題吧。

開始排查網(wǎng)路。換A的物理端口、換交換機、換網(wǎng)線、換對端的物理端口等等一系列措施之后，發(fā)現(xiàn)問題依然存在。

第三步：

采用網(wǎng)絡探測設備，從交換機兩側端口抓包，分析一個tcp連接的建立過程時間消耗在哪里。分析后發(fā)現(xiàn)，200ms的延時，都是在B測。即一個tcp連接建立過程在A側和交換機側幾乎沒有什么時間消耗。

第四步：

B側多臺分區(qū)共用一個物理機。猜測是否是分區(qū)過多導致。當只有一個LPAR啟動的時候，沒有ping的延時，當啟動一部分LPAR時候，延時較小，當所有LPAR均啟動，ping 延時較大。

問題根本原因：

此時，問題水落石出，原來是由于分區(qū)過多導致了B回復A的ping有了延時。那么為什么會出現(xiàn)這種情況呢？一個物理機上CPU資源是有限的（本環(huán)境中是3顆），即使只有一個LPAR，其上面的N個進程也會去輪流使用CPU，何況此時是M臺LPAR，MN個進程去輪流使用這三個CPU，當然調度算法并不是這么簡單，這里僅僅是從理論上做個說明。

假設每個CPU時間片是10ms，那么極端情況下，一個進程要等到CPU需要等待（MN-1）*10（ms）/3。

況且，這么多LPAR的進程輪詢一遍CPU，CPU里面的cache 數(shù)據(jù)估計早就被擠走了，重新加載是比較耗時的。

應對方法：

之前LPAR也設置了保障的CPU（MIPS數(shù)量的保障），但只有數(shù)量沒有質量（上述提到的CPU cache問題，即親和性問題）

應對方法是：將重要的LPAR分配dedicated CPU，保證CPU資源的質量，保證輪詢CPU的客戶盡量少，這樣CPU cache中的數(shù)據(jù)盡量不被清走。經(jīng)驗證，ping延時基本消失，方法有效。

本案例是一起看似是網(wǎng)絡問題，但實際是資源調度方式的問題。

順便提一句，很多情況下，客戶端的響應時間不穩(wěn)定都是由服務器端的服務能力不穩(wěn)定造成的。一般情況下都是應用、數(shù)據(jù)庫的問題造成。而本案例是操作系統(tǒng)層面答復ping出現(xiàn)間歇性延時，很容易誤導我們的分析判斷。