Linux 核心可讓您以低層級控制 I/O 排程封鎖裝置的方式。Linux 各版本的預設值差異極大。測試顯示、截止日期通常會提供最佳結果、但有時 NOOP 會稍微好一點。效能差異最小、但如果需要從資料庫組態擷取最大可能效能、請測試這兩個選項。在許多組態中、 CFQ 是預設值、而且已證明資料庫工作負載的效能有重大問題。

如需設定 I/O 排程器的指示、請參閱相關的 Linux 廠商文件。

部分客戶在網路中斷期間遭遇當機、因為多重路徑常駐程式未在其系統上執行。在最新版本的 Linux 上、作業系統的安裝程序和多重路徑常駐程式可能會讓這些作業系統容易受到此問題的影響。套件已正確安裝、但未設定為在重新開機後自動啟動。

例如，RHEL 9.7 上的多路徑守護程式的預設配置可能如下所示：

您可以使用下列命令來修正此問題：

為 SAN 設備設定適當的佇列深度，以避免 I/O 瓶頸。Linux 上的預設佇列深度通常設定為 128，這可能會導致 Oracle 資料庫出現效能問題。佇列深度設定過高會導致 I/O 排隊過多，從而導致延遲增加和吞吐量降低。設定得太低會限制未完成的 I/O 請求數量，從而降低整體效能。對於ASA r2 上的 Oracle 資料庫工作負載，佇列深度 64 通常是一個不錯的起點，但可能需要根據特定的工作負載特性和效能測試進行調整。

ASM鏡射可能需要變更Linux多重路徑設定、以允許ASM辨識問題並切換至其他故障群組。大部分關於「不完整」的ASM組態ONTAP 都使用外部備援、這表示資料保護是由外部陣列提供、而ASM不會鏡射資料。某些站台使用具有一般備援的ASM來提供雙向鏡像、通常是跨不同站台。

對於支援主動-主動多路徑的ASA r2 系統，應調整這些多路徑設定。由於所有路徑都處於活動狀態並進行了負載平衡，因此不需要無限期排隊。相反，多路徑參數應優先考慮效能和快速故障復原。這種行為對於 ASM 鏡像很重要，因為 ASM 必須收到 I/O 失敗才能在備用 LUN 上重試 I/O。如果 I/O 無限期地排隊，ASM 無法觸發故障轉移。

在 Linux 中設定下列參數 multipath.conf 用於 ASM 鏡像的 ASM LUN 檔案：

這些設定會為 ASM 裝置建立 120 秒的逾時。逾時會計算為 polling_interval * no_path_retry 秒。在某些情況下可能需要調整確切的值、但 120 秒的逾時時間應足以滿足大部分的使用需求。具體而言、 120 秒的時間應該能讓控制器接管或恢復、而不會產生 I/O 錯誤、導致故障群組離線。

較低 no_path_retry 此值可縮短 ASM 切換至替代故障群組所需的時間、但這也會增加在維護活動（例如控制器接管）期間不必要的容錯移轉風險。仔細監控 ASM 鏡像狀態、即可降低風險。如果發生不必要的容錯移轉、只要執行重新同步的速度相對較快、鏡像就能快速重新同步。如需更多資訊、請參閱 ASM Fast Mirror Resync 上的 Oracle 說明文件、以瞭解所使用的 Oracle 軟體版本。