資源供給：IO子系統之三

        簡單案例說明：某社保系統在業務高峰期總是效能表現很差，從AWR報告中可以看出，負載壓力不是很大，只是IO的響應速度很慢。在負載壓力一般的情況下，IO響應速度緩慢只能是意味著下面兩個問題：（1）、IO子系統故障  （2）、IO子系統配置不當。檢查作業系統，沒有發現IO子系統錯誤狀況，檢查Raid Cache工作正常，直接測試物理磁碟的IO，可以承載正常的負載。我們判斷是vxvm的佇列設定有問題，交給Veritas工程師檢查，Veritas工程師檢查之後確認是Vxvm部署不當，佇列大小不足並且其中有一個模組未部署安裝。
       卷管理器是IO子系統的重要部件，我們可以看到常見的卷管理器： Veritas Vxvm，Oracle ASM，IBM LVM，HP LVM等等。特別是Oracle ASM作為一個卷管理器幾乎會成為今後所有資料庫系統設定的標配，ASM卷管理器的效能問題將成為IO子系統中的重要關節。
       在高併發性系統，裝置的佇列大小是系統響應時間的關鍵所在，大量的應用實踐證明在高吞吐量系統中，合適的佇列大小可以提高系統30%甚至50%的併發能力。

       我們來看整個IO子系統的通路：
      CPU ==> CPU to Cache ==> Cache to filesystem(buffer) ==> LV ==> HBA ==> SAN Switch ==> Disk Control == > Disk Array cache ==> Disk

     作為一個優秀的IO系統，後續的部件必須可以承載前面輸送過來的壓力，而實際情況往往是後續部件的單件處理能力遠遠比不上前面的鏈路。這個時候，我們除了通過擴充套件配置使整體處理能力相互匹配之外，一個最為重要的措施就是利用快取（佇列）以使前面輸送過來的負載均勻化，基本而言，後續的佇列大小要大於前面的佇列大小。

    我們來看：
    LVM buffer(LVM一般通過Buffer來進行緩衝，可能部分系統也會採用Queue的方式）
    HBA Queue
    SAN Switch Queue
    Disk Control Queue
   Disk Queue

  由於Disk是其中最慢的措施，一般在高吞吐量的系統中，預設的 Disk Queue幾乎總是無法滿足需求，需要進行增加。而HBA和SAN Switch Queue也經常需要調整，LVM buffer則要保持足夠使用，對於ASM來說就是ASM Instance SGA。  

     
     
        

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/92650/viewspace-776899/，如需轉載，請註明出處，否則將追究法律責任。