一、 存儲能力探測

當業務吞吐量不能如預期增加，可以考慮是否是由于存儲的瓶頸導致。

業務系統運行起來后，可以提煉其中的IO模型，按照IO模型，有針對性的進行存儲方面的規劃和測試。有不少工具可以用來探測LPAR所用的存儲的最大能力，本文以Orion工具為例介紹。

1.1 IO模型

IO模型包括：

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

數據收集來源除了上述介紹的IOPS、帶寬指標，還需要關注IO的大小。IO的大小可以通過帶寬/IOPS來計算，但更細致的數據可以通過NMON中DISKAVGRIO/DISKAVGWIO來讀取，畢竟帶寬/IOPS計算得出的IO Size是某個時間段的平均值，而真實場景中每一秒的情況可能與平均值相差甚遠。

[[221065]]

1.2 存儲能力探測工具-Orion

Orion工具是由Oracle開發，用于探測Oracle數據庫所在的存儲在不同IO模型下的最大IO能力，預測Oracle的最大讀寫能力。Orion可模擬Oracle數據庫IO負載（采用與Oracle相同的IO軟件棧），可模擬Oracle Automatic Storage Management提供的條帶效果。

本測試中針對某一文件進行100%的寫操作，寫操作的類型為順序寫，每個寫IO大小為8K。

Orion按照上述指定參數施壓，自動地、逐漸地增加并發寫的進程數，直到Orion認為吞吐量不再增加。測試結束后，從trace文件中提取有用信息，如下圖：

Orion還可以不進行參數設置，自動對存儲的IOPS、帶寬的最大能力進行探測，是一款不錯的小工具。

二、 存儲問題定位

從用戶的角度來說，性能問題最直觀的感受是應用響應時間或者業務處理時間變長，性能問題是系統性的，問題可能出現在各個環節。通常情況下，最先排查的是CPU、內存等服務器內在的原因，當服務器內在原因被初步排除后，才會排查網絡IO、磁盤IO的問題。

即使確定是磁盤IO導致的，也要分析整個IO路徑，分析IO瓶頸是主機/網絡/存儲中的哪個環節導致的。

2.1 主機側

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

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

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

2.2 交換網絡

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

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

2.3 存儲側

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

常見原因如硬盤性能達到上限、鏡像帶寬達到上限、存儲規劃（如條帶過小）、硬盤域和存儲池劃分（例如劃分了低速的磁盤）、LUN對應的存儲緩存設置過小、IO的Qos限制的磁盤IO的帶寬、存儲接口模塊數量過小、RAID劃分（比如RAID10>RAID5>RAID6）、配置快照、克隆、遠程復制等增值功能拖慢了性能、存儲控制器的CPU利用率過高、LUN未格式化完成引起短時的性能問題。