前言

控制著作業系統io的設定。該引數只作用於檔案系統。它有四個值可供設定，分別是：{none | setall | directIO | asynch }。該引數預設值受資料庫版本和作業系統型別及作業系統版本影響。

從oracle 10G開始，對於ASM磁碟管理的情況，filesystem_option引數不作用於ASM磁碟管理的資料庫。

 

 

 I/O 說明

說明

在Synchronous   I/O 的機制下，若一個Oracle程式想呼叫一個I/O請求，那麼必須等待其他請求完成後才能呼叫。例如，如果它發起對幾個資料塊的讀取，那麼程式就必須等待它把所有資料塊都讀取到記憶體之後，才能進行下一個動作。

說明

在Asynchronous  I/O 的機制下，程式可以與I/O請求同時工作。對已經讀取的資料塊，可以直接進行處理，不用等待所有資料塊全部載入完畢再處理。

說明

在buffer I/O機制下，作業系統有自己的一套用於維護磁碟資料的cache，而不是直接從process buffer讀取或者寫入。其原理是從磁碟中讀取資料寫入cache，然後複製至process buffer。或者從process buffer中複製至cache然後寫入到磁碟中。

說明

Direct I/O  能讓所有的讀和寫的請求直接來自於磁碟，繞過作業系統快取。

在ASM磁碟管理下，為了防止叢集管理的資料庫的資料損壞，必須直接使用Direct I/O。

對於使用檔案系統的資料庫環境，Oracle發出的讀取請求可以從OS緩衝區中得到滿足，而一旦啟用direct I/O又不增加SGA大小，將導致磁碟讀取需要更多的時間才能完成。為了充分利用direct I/O，需要將用於OS快取部分增加到資料庫SGA中。

 

 filesystemio_options 和liao 引數說明

disk_asynch_io 是相當於主開關，不管是檔案系統還是裸裝置，它都控制著非同步io的開啟與關閉，filesystemio_options是子開關，控制著檔案系統上的非同步io。如果資料庫使用了檔案系統， 那麼I/O只受filesystemio_options控制。

的情況

RAC 環境下，direct I/O是預設開啟的。並且在ASM磁碟管理下，I/O肯定是非同步的，而且直接做的是direct I/O。所以，對於ASM磁碟管理，不用設定filesystemio_options，只要設定合理的SGA和PGA大小即可。（詳情見mos：Document 751463.1）

單機的情況

在檔案系統檔案管理的情況下，那麼非同步I/O的開啟則受filesystemio_options的控制影響。

以下是Oracle官方檔案系統管理的情況下，使用同/非同步IO，快取/直接IO的設定矩陣說明。

檔案系統設為開啟非同步和直接IO那麼就選setall選項，開啟同步和直接IO就選directIO選項。

 

 

引數配置說明

1 、單機環境下，非同步IO受filesystemio_options控制，此引數用於特定的平臺，各個作業系統平臺預設值不一樣，linux平臺預設是none，更改選項語句格式：

ALTER SYSTEM SET FILESYSTEMIO_OPTIONS={SETALL|ASYNCH| DIRECTIO|NONE}SCOPE=SPFILE;

2 、RAC環境下，Asynchronous IO受DISK_ASYNCH_IO引數控制，預設是TRUE，更改選項語句格式：

ALTER SYSTEM SET DISK_ASYNCH_IO={FALSE|TRUE} SCOPE=SPFILE;

Oracle 建議您將此引數設定為其預設值。但是，如果asynchronous  I/O 效能不穩定，則可以將此引數設定為false，以禁用asynchronous  I/O 。如果您的平臺不支援磁碟asynchronous  I/O ，則此引數不起作用。

 

引數配置建議

在linux下FILESYSTEMIO_OPTIONS引數配置建議：

filesystem_option 引數，只有在9i，10G的時代，AIX、HP小機，使用祼裝置的情況下設定filesystem_option為非同步+直接I/O，電信也是基於這樣的環境下設定該引數，10G開始，有了ASM，filesystem_option可以由Oracle自動配置，特別是11G及以上都是預設none，而對於檔案系統，不建設設定為非同步+直接I/O。

setall ： 儲存I/O效能良好的情況下設定，可以大幅提升I/O總體效能，尤其是寫效能，如果多套資料庫公用一套儲存則不建議設定此引數。使用場景除了小機和裸裝置，檔案系統如果要開啟的話，需要具備兩點：1、把檔案系統的cache記憶體加到SGA上去，變向的保證快取量，2、修改前作業系統磁碟效能指標正常不存在瓶頸。磁碟監控的主要iostat指標如下：

使用率（%util ） ：是指磁碟 I/O  的百分比。過高的使用率（比如達到 80% 及以上），通常意味著磁碟 I/O  存在效能瓶頸。

佇列長度（aqu-sz ）: 平均請求佇列長度

IOPS （r/s+ w/s ）： 是指每秒的 I/O  請求數。

吞吐量（rkB/s+wkB/s ） ：是指每秒的 I/O  請求大小。

響應時間（r_await+w_await ） ：是指 I/O  請求從發出到收到響應的間隔時間。

* 對於 aqu-sz ，r/s+ w/s ，rkB/s+wkB/s ，r_await+w_await 的幾個指標，基線是每個環境都不一樣的，如果要定基線找幾個環境開始監控這些指標，作為正常時間段的基線。

注意：除了作業系統層面指標出現大幅異常，我們同樣需要注意資料庫層面的等待事件（db file sequential/scattered read,direct path read/write等），特別需要注意開啟前後與I/O相關的等待響應時間是否發生大幅變化。

directIO ： 直接繞過快取，使用directIO引數意味著Synchronous  I/O 需要等待其他請求完成後才能呼叫，對儲存壓力較大。且消耗CPU資源，不建議在生產上設定此引數。

asynch ： 非同步IO可以提高效能，但是顯而易見的是對磁碟處理IO能力有較高要求，否則提交的處理請求多，處理能力跟不上，根本無法達到提高效能的要求。（開啟前請先檢查磁碟IO處理能力，若磁碟效能已在臨界值，開啟後總體效能反而會有明顯下降）

None ： 預設引數，由Oracle自身調節，有較好的綜合表現。

 

 

實驗測試

測試結果：相同的測試環境下，none的整體效能優於其他三種。（由於採用的是虛擬化環境測試經過僅供參考）。具體測試結果如下：

測試工具：HammerDB

測試環境：centos7.4 + oracle11.2.0.4單機 虛擬化環境8核cpu、12GB記憶體

資料庫記憶體配置：SGA 2.4G  PGA 798M

模型樣本資料量：200g資料，5倉庫，測試使用者20

對照指標：TMP，為每分鐘處理事務數。每分鐘處理值越高代表資料庫總體處理效能越好。

總結：在儲存效能一般的情況下設定setall和Asynch資料庫總體效能都會下降。

 

設定Setall TMP值：

 

設定directIO TMP值：  

設定Asynch TMP值：

設定None TMP值：

實驗資料對照表

	setall	directIO	Asynch	None	量化指標
Cpu 使用者使用峰值	78%	50%	38%	36%	Utilization ：Idle
Cpu 平均功耗排名	4	3	1	2	值越小代表平均功耗越高
記憶體（空閒記憶體）	5.3G ～4.3G	5G ～3.8G	4.8G ～1.2G	6G ～0.1G	Memory （K Bytes）
記憶體使用排名	4	2	3	1	值越小代表平均使用率越高
I/O 繁忙度	50% ～100%	72% ～100%	25% ～100%	80% ～100%	Iostat:vdc percent busy
I/O 讀/寫峰值（kb/s）	1100/5500	300/6200	220/4800	1200/5300	Iostat: vdc Writes/Reads Per Second

圖1-1Cpu使用者使用率監控圖

圖1-2記憶體監控圖

 

圖1-3 IO讀寫監控圖

從圖1-1 Cpu使用者使用率監控圖得出結論，設定成setall時，cpu平均使用率是最低的，那麼說明此引數cpu消耗較小。ASYNCH消耗cpu最高，NONE第二，其次DIRECTIO。

從圖1-2 分析，在壓力測試期間記憶體佔用最高的是NONE，第二是ASYNC，第三是DIRECTIO，最後是SETALL。

從圖1-3 IO讀寫監控圖分析得到結論，設定成setall時，每秒讀平均流量明顯高於引數設定成none和async時，由於實驗環境I/O效能存在一定的瓶頸，I/0 繁忙度很容易達到100%。在生產發生問題時，同樣表現為I/O讀流量較高。如下圖所示：

總結

根據以上實驗資料得出結論，FILESYSTEMIO_OPTIONS引數設定成SETALL後作業系統CPU和記憶體佔用情況沒有出現很大的異常，在I/O讀方面有較大的變化。設定成SETALL慢是因為資料庫出現了嚴重的I/O等待，導致資料庫整體變慢。導致變慢的原因主要有兩個：1、記憶體使用量少，說明cache到記憶體的資料少了，大部分壓力直接落在了磁碟I/O上，這時候應適當調整SGA大小（原本Oracle發出的讀取請求可以從OS緩衝區中得到滿足，而一旦啟用setall意味著開啟了direct I/O，這時候應該增加資料庫SGA大小，否則將導致磁碟讀取需要更多的時間才能完成）；2、儲存I/O瓶頸，無法提供更高的I/O吞吐量，大量的阻塞會話來不及處理，導致資料庫系統整體變慢。所以一定要在儲存效能良好的情況下設定SETALL引數。

下圖是生產故障時awr報告的等待事件部分，總體I/O等待佔據了整個DB time的68.1%,且平均I/0 等待達到了3ms，正常情況下，平均I/0等待在應在1ms以下。直接路徑讀等待事件的平均I/O延遲更是達到了7ms，佔據了整個DBtime的19.9%。顯然當時資料庫總體效能已經出現了嚴重的問題，由於相關I/O等待事件的大量堵塞，導致資料庫響應速度整體變慢。

圖1-4 故障時間I/O等待

圖1-4 正常執行時I/O等待

 

七  論證調整調大SGA 後效能變化

測試工具：HammerDB

測試環境：centos7.4 + oracle11.2.0.4單機 虛擬化環境8核cpu、12GB記憶體

資料庫記憶體配置：SGA 4.8G  PGA 798M

模型樣本資料量：200g資料，5倉庫，測試使用者20

引數設定filesystem_option設定為SETALL

SGA 設定4.8G TMP值：

SGA 設定2.4G TMP值：

 

SGA 設定4.8G 每秒讀寫值：

SGA 設定2.4G 每秒讀寫值：

根據以上實驗資料得出結論，FILESYSTEMIO_OPTIONS引數設定成SETALL情況下，調大資料庫SGA，資料庫總體效能有所改善，且磁碟每秒讀平均在200k/s以下。總體TPM有所提升，且每秒讀壓力有所降低。