點(diǎn)擊上方“朱小廝的博客”，選擇“設(shè)為星標(biāo)”

后臺(tái)回復(fù)”加群“加入公眾號(hào)專屬技術(shù)群

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

本文由社區(qū)專家楊建旭根據(jù)社區(qū)活動(dòng)整理，包括其分享的相關(guān)知識(shí)點(diǎn)分享和大家關(guān)心的典型問題，供大家參考。

? ?01?評(píng)估IO能力的前提? ?

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

(一)IO模型

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

• 最基本的模型包括：IOPS、帶寬和IO大小

• 如果是磁盤IO，那么還需要關(guān)注：磁盤IO分別在哪些盤、讀IO和寫IO的比例、讀IO是順序的還是隨機(jī)的、寫IO是順序的還是隨機(jī)的。

(二)為什么要提煉IO模型

不同模型下，同一臺(tái)存儲(chǔ)，或者說同一個(gè)LUN，能夠提供的IOPS、帶寬（MBPS）、響應(yīng)時(shí)間3大指標(biāo)的最大值是不一樣的。

當(dāng)存儲(chǔ)中提到IOPS最大能力的時(shí)候，一般采用隨機(jī)小IO進(jìn)行測(cè)試，此時(shí)占用的帶寬是非常低的，響應(yīng)時(shí)間也會(huì)比順序的IO要長(zhǎng)很多。如果將隨機(jī)小IO改為順序小IO，那么IOPS還會(huì)更大。當(dāng)測(cè)試順序大IO時(shí)，此時(shí)帶寬占用非常高，但I(xiàn)OPS卻很低。因此，做IO的容量規(guī)劃、性能調(diào)優(yōu)需要分析業(yè)務(wù)的IO模型是什么。

? ?02?評(píng)估工具? ?

(一)磁盤IO評(píng)估工具

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

有的工具可以模擬應(yīng)用場(chǎng)景，比如orion是oracle出品，模擬Oracle數(shù)據(jù)庫(kù)IO負(fù)載（采用與Oracle相同的IO軟件棧）。即模擬oracle應(yīng)用對(duì)文件或磁盤分區(qū)進(jìn)行讀寫（可指定讀寫比例、io size，順序or隨機(jī)）這里就需要提前知道自己的IO模型。如果不知道，可以采用自動(dòng)模式，讓orion自動(dòng)的跑一遍，可以得出不同進(jìn)程的并發(fā)讀寫下，最高的IOPS、MBPS，以及對(duì)應(yīng)的響應(yīng)時(shí)間。

比對(duì)dd，僅僅是對(duì)文件進(jìn)行讀寫，沒有模擬應(yīng)用、業(yè)務(wù)、場(chǎng)景的效果。

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

(二)網(wǎng)絡(luò)IO評(píng)估工具

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

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

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

? ?03?主要監(jiān)控指標(biāo)和常用監(jiān)控工具? ?

(一)磁盤IO

對(duì)于存儲(chǔ)IO：unix、linux平臺(tái)，Nmon、iostat是比較好的工具。nmon用于事后分析，iostat可用于實(shí)時(shí)查看，也可以采用腳本記錄下來事后分析。

1.IOPS

• 總IOPS：Nmon DISK_SUMM Sheet：IO/Sec

• 每個(gè)盤對(duì)應(yīng)的讀IOPS ：Nmon DISKRIO Sheet

• 每個(gè)盤對(duì)應(yīng)的寫IOPS ：Nmon DISKWIO Sheet

• 總IOPS：命令行iostat -Dl：tps

• 每個(gè)盤對(duì)應(yīng)的讀IOPS ：命令行iostat -Dl：rps

• 每個(gè)盤對(duì)應(yīng)的寫IOPS ：命令行iostat -Dl：wps

2.帶寬

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

• 每個(gè)盤對(duì)應(yīng)的讀帶寬：Nmon DISKREAD Sheet

• 每個(gè)盤對(duì)應(yīng)的寫帶寬：Nmon DISKWRITE Sheet

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

• 每個(gè)盤對(duì)應(yīng)的讀帶寬：命令行iostat -Dl：bread

• 每個(gè)盤對(duì)應(yīng)的寫帶寬：命令行iostat -Dl：bwrtn

3.響應(yīng)時(shí)間

• 每個(gè)盤對(duì)應(yīng)的讀響應(yīng)時(shí)間：命令行iostat -Dl：read - avg serv，max serv

• 每個(gè)盤對(duì)應(yīng)的寫響應(yīng)時(shí)間：命令行iostat -Dl：write - avg serv，max serv

4.其他

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

(二)網(wǎng)絡(luò)IO

1.帶寬

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

• Nmon：NET Sheet

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

2.響應(yīng)時(shí)間

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

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

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

? ?04?性能定位與優(yōu)化? ?

(一)對(duì)磁盤IO爭(zhēng)用的調(diào)優(yōu)思路有哪些？

典型問題：針對(duì)主要爭(zhēng)用是IO相關(guān)的場(chǎng)景下，調(diào)優(yōu)的思路有哪些？主要的技術(shù)或者方法是什么？

一、首先要搞清楚IO爭(zhēng)用是因?yàn)?/strong>應(yīng)用等層面的IO量過大導(dǎo)致，還是系統(tǒng)層面不能承載這些IO量。

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

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

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

二、存儲(chǔ)問題的分析思路

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

IO從應(yīng)用->內(nèi)存緩存->塊設(shè)備層->HBA卡->驅(qū)動(dòng)->交換網(wǎng)絡(luò)->存儲(chǔ)前端->存儲(chǔ)cache->RAID組->磁盤，經(jīng)過了一個(gè)很長(zhǎng)的鏈條。需要逐段分析：

1、主機(jī)側(cè)

當(dāng)主機(jī)側(cè)觀察到的時(shí)延很大，存儲(chǔ)側(cè)的時(shí)延較小，則可能是主機(jī)側(cè)或網(wǎng)絡(luò)存在問題。

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

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

2、網(wǎng)絡(luò)側(cè)

當(dāng)主機(jī)側(cè)觀察到的時(shí)延很大，存儲(chǔ)側(cè)的時(shí)延較小，且排查主機(jī)側(cè)無問題時(shí)，則性能問題可能出現(xiàn)在鏈路上。

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

3、存儲(chǔ)側(cè)

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

常見原因如硬盤性能達(dá)到上限、鏡像帶寬達(dá)到上限、存儲(chǔ)規(guī)劃（如條帶過小）、硬盤域和存儲(chǔ)池劃分（例如劃分了低速的磁盤）、thin LUN還是thick LUN、LUN對(duì)應(yīng)的存儲(chǔ)的緩存設(shè)置（緩存大小、緩存類型，內(nèi)存還是SSD）、IO的Qos限制的磁盤IO的帶寬、LUN優(yōu)先級(jí)設(shè)置、存儲(chǔ)接口模塊數(shù)量過小、RAID劃分（比如RAID10>RAID5>RAID6）、條帶寬度、條帶深度、配置快照、克隆、遠(yuǎn)程復(fù)制等增值功能拖慢了性能、是否有重構(gòu)、balancing等操作正在進(jìn)行、存儲(chǔ)控制器的CPU利用率過高、LUN未格式化完成引起短時(shí)的性能問題、cache刷入磁盤的參數(shù)（高低水位設(shè)置），甚至數(shù)據(jù)在盤片的中心還是邊緣等等。

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

(二)關(guān)于低延遲事務(wù)、高速交易的應(yīng)用在IO方面可以有哪些調(diào)優(yōu)思路和建議？

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

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

1.從業(yè)務(wù)角度

比如說業(yè)務(wù)上不需要保存日志，那就不用寫IO。或者保存級(jí)別不高，那就可以只寫一份數(shù)據(jù)，對(duì)于保存級(jí)別較高的日志，一般要雙寫、或多寫。

2.從存儲(chǔ)介質(zhì)角度

• 1）可以全部采用SSD

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

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

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

• 5）增加LUN所對(duì)應(yīng)的存儲(chǔ)服務(wù)器的緩存

3.從配置的角度

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

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

4.IO路徑的角度

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

(三) 網(wǎng)絡(luò)IO問題定位思路和方法

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

(四)誤判為IO問題的案例

很多時(shí)候，應(yīng)用響應(yīng)時(shí)間很慢，看似是IO問題，實(shí)則不然，這里舉兩個(gè)例子。

1.案例分享：Oracle buffer等待占總時(shí)間的大頭

在一個(gè)場(chǎng)景中，oracle的awr報(bào)告top10事件的第一名是：buffer busy waits

buffer busy waits是個(gè)比較general的等待，是session等待某個(gè)buffer引起的，但具體是什么buffer并不清楚，比如log sync等待也會(huì)引起buffer busy wait。這是個(gè)連帶指標(biāo)，分析是暫且不管，需要看看他臨近的問題事件是什么。

awr報(bào)告top10事件的第二名是enq：TX - index contention

這里的臨近事件就是enq：TX - index contention， index contention常由大量并發(fā)INSERT 造成的 index split 引起，也就是說不斷更新索引的過程中，二叉樹不斷長(zhǎng)大。需要分裂，分裂的時(shí)候，其他session就需要等著。（這里的分析需要些數(shù)據(jù)庫(kù)知識(shí)）

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

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

2.案例分享：ping延時(shí)間歇性暴增

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

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

第二步：那么好，著手定位網(wǎng)絡(luò)問題吧。開始排查網(wǎng)路。換A的物理端口、換交換機(jī)、換網(wǎng)線、換對(duì)端的物理端口等等一系列措施之后，發(fā)現(xiàn)問題依然存在。

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

第四步：B側(cè)多臺(tái)分區(qū)共用一個(gè)物理機(jī)。猜測(cè)是否是分區(qū)過多導(dǎo)致。當(dāng)只有一個(gè)LPAR啟動(dòng)的時(shí)候，沒有ping的延時(shí)，當(dāng)啟動(dòng)一部分LPAR時(shí)候，延時(shí)較小，當(dāng)所有LPAR均啟動(dòng)，ping 延時(shí)較大。

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

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

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

應(yīng)對(duì)方法：之前LPAR也設(shè)置了保障的CPU（MIPS數(shù)量的保障），但只有數(shù)量沒有質(zhì)量（上述提到的CPU cache問題，即親和性問題）

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

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

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

想知道更多？掃描下面的二維碼關(guān)注我

當(dāng)當(dāng)百萬圖書每滿100-50（活動(dòng)時(shí)間10月24~11.1）。使用我的優(yōu)惠嗎：2CGJZK，還可以享受：實(shí)付200-30（全場(chǎng)自營(yíng)圖書可用，優(yōu)惠券到期時(shí)間11-01），實(shí)際為花170買400元圖書。

朕已閱?