資源供給:IO子系統之二

yuntui發表於2016-11-03
     案例描述:
            某運營商的dbra備份系統,備份構建在vxvm和vxfs檔案系統之上,序列更新的速度基本理想。由於無法達到更新目標,透過增加並行來增加IO寫速度,結果並行度加大之後,iops快速下跌,io子系統無法提供併發能力。由於對於vxvm不是很瞭解,又沒有廠商支援,測試了vxvm依賴的磁碟層次,發現磁碟層次可以提供很好的並行度擴充。簡單的構建了一個hp-ux預設的vxfs,也可以很好的進行並行擴充套件,現在可以判斷是vxvm的並行能力出現了問題,估計是vxvm佇列的問題,由於缺乏支援,無法對於vxvm作出最佳化調整。在客戶的支援下,放棄了vxvm之後,建立在hp-ux的lvm之上,具有很好的並行度擴充,達到了最佳化目標。

           卷管理器和檔案系統是方便使用者使用的磁碟基本管理單元,在帶來了方便性的同時也可能會帶來些效能方面的問題。
          
           檔案系統帶來的主要障礙:
          (1)、日誌卷會對於更新帶來比較大的壓力。
                       檔案系統的日誌裝置對於頻繁更新的檔案系統可能會帶來一定的壓力,這個時候可以採用獨立日誌裝置來避免日誌裝置對於檔案系統的IO影響。
          (2)、後設資料過大,會使檔案系統的搜尋延遲變強,特別是在尋找自由空間的時候。後設資料過大主要表現在檔案系統中的檔案過多,達到幾千幾萬的範疇。從這點考慮必須考慮Oracle資料庫的資料檔案不要和Oracle安裝軟體處於相同的檔案系統。同樣太大的檔案會需要更多的inode,自然也就需要更高的後設資料搜尋成本。
          (3)、檔案系統碎片,檔案系統碎片導致的問題事實上就是後設資料過大,使其尋求自由空間的成本變高。
            一般現代檔案系統採用Block,Extent的方式來管理檔案,主要是為了提高效能。而Extent的全域性管理則一般使用點陣圖。大家只要簡單考慮下Oracle的表空間管理,只要把檔案系統的空間管理類似於Oracle表空間管理即可。在點陣圖模式下,Extent的大小並不會帶來多大的效能問題,但是為了支援Oracle全表掃描,必須要使檔案系統的Extent大於Oracle全表掃描的範疇,一般為1M。當系統中存在大量的小空閒Extent的時候就會存在比較大的效能問題,在搜尋自由空間的成本會大幅度增加,這個時候可能需要對於檔案系統進行碎片整理。
           一般來說,建議檔案系統的Block Size=Oracle Block Size, Oracle extent size:=File system extent size * N,File system Exetnt Size至少要1M大小,並且是1M的倍數。
          (4)、檔案鎖,相對於lv使其併發能力會降低。
            檔案操作和lv操作不同,一般需要增加檔案鎖,從而使其併發能力下降。不過現代檔案系統都開始進行不需要檔案鎖的實踐,增加了並行IO,降低或者徹底消除了檔案鎖的需求。

         
           檔案系統的Buffer Cache:
          檔案系統的Buffer Cache在兩個層面會帶來收益:
          (1)、讀操作
          (2)、預讀快取

           在檔案系統的Buffer帶來好處的同時可能會給Oracle帶來負面的影響,主要因素在於檔案系統Buffer和Oracle SGA Buffer共享使用實體記憶體。當檔案系統需要更多的記憶體而作業系統無法提供的時候將從Oracle SGA Buffer偷取記憶體,把Oracle SGA Buffer交換到磁碟上,從而導致Oracle效能大幅度下降。

           為了使檔案系統快取不影響到Oracle SGA Buffer,必須保證檔案系統快取和Oracle SGA Buffer的共用記憶體不超過作業系統記憶體memory pin部分。一般而言,由於Oracle資料庫具有更加重要的價值,一般來說對於Oracle資料庫來說不建議快取檔案,或者僅僅分配很小的快取空間。
          比如:我們設定檔案系統快取最大不超過5%的記憶體,並且使系統有限交換檔案頁,從而保留SGA Buffer在實體記憶體之中。具體如何設定,參考各自作業系統和檔案系統。

         
       

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

相關文章