共用方式為

Azure NetApp Files 單一磁碟區上的 Oracle 資料庫效能

  • 發行項

本文討論以下有關雲端 Oracle 的主題。 這些可能是資料庫管理員、雲端架構設計師或儲存體架構設計人員特別感興趣的主題：

  • 當您驅動線上交易處理 (OLTP) 工作負載 (大部分是隨機 I/O) 或線上分析處理 (OLAP) 工作負載 (大部分是循序 I/O) 時，效能看起來會像什麼？
  • 一般 Linux 核心 NFS (kNFS) 用戶端與 Oracle 自己的 Direct NFS 用戶端之間的效能有何差異？
  • 就頻寬而言，單一 Azure NetApp Files 磁碟區的效能是否足夠？

重要

如需 Oracle dNFS 的正確和最佳部署，請遵循此處所述的修補指導方針。

測試環境和元件

下圖說明用於測試的環境。 為了一致性和簡單起見，會使用 Ansible 劇本來部署測試床的所有元素。

Oracle 測試環境

虛擬機器組態

測試會針對虛擬機器使用下列設定：

  • 作業系統：
    RedHat Enterprise Linux 7.8 (wle-ora01)
  • 執行個體類型：
    測試使用了兩個模型：D32s_v3 和 D64s_v3
  • 網路介面計數：
    一個 (1) 放在子網路 3
  • 磁碟：
    Oracle 二進位檔和 OS 放置在單一進階磁碟中

Azure NetApp Files 設定

測試使用下列 Azure NetApp Files 設定：

  • 容量集區大小：
    已設定各種集區大小：4 TiB、8 TiB、16 TiB、32 TiB
  • 服務層級：
    Ultra (每 1 TiB 的配置磁碟區容量使用每秒 128 MiB 頻寬)
  • 磁碟區：
    已評估一次和兩次磁碟區測試

工作負載產生器

測試使用工作負載產生的 SLOB 2.5.4.2。 SLOB (Silly Little Oracle Benchmark) 是 Oracle 領域眾所周知的工作負載產生器，其設計目的是利用 SGA 緩衝的實體 I/O 工作負載來加壓和測試 I/O 子系統。

SLOB 2.5.4.2 不支援可插式資料庫 (PDB)。 因此，已將變更新增至 setup.sh 和 runit.sh 指令碼，以新增 PDB 支援。

下列各節將說明測試所使用的 SLOB 變數。

工作負載 80% 選取，20% 更新 | 隨機 I/O – slob.conf 變數

UPDATE_PCT=20
SCAN_PCT=0
RUN_TIME=600
WORK_LOOP=0
SCALE=75G
SCAN_TABLE_SZ=50G
WORK_UNIT=64
REDO_STRESS=LITE
LOAD_PARALLEL_DEGREE=12

工作負載 100% 選取 | 循序 I/O – slob.conf 變數

UPDATE_PCT=0
SCAN_PCT=100
RUN_TIME=600
WORK_LOOP=0
SCALE=75G
SCAN_TABLE_SZ=50G
WORK_UNIT=64
REDO_STRESS=LITE
LOAD_PARALLEL_DEGREE=12

Database

用於測試的 Oracle 版本是 Oracle Database Enterprise Edition 19.3.0.0。

Oracle 參數如下所示：

  • sga_max_size: 4096M
  • sga_target: 4096
  • db_writer_processes: 12
  • awr_pdb_autoflush_enabled: true
  • filesystemio_options: SETALL
  • log_buffer: 134217728

已為 SLOB 資料庫建立 PDB。

下圖顯示已建立名為 PERFIO 的資料表空間，其大小為 600 GB (20 個資料檔案，每個檔案 30 GB)，用於裝載四個 SLOB 使用者結構描述。 每個使用者結構描述的大小為 125 GB。

Oracle Database

效能計量

目標是報告應用程式所經歷的 IO 效能。 因此，本文中的所有圖表都會使用 Oracle 資料庫透過其自動工作負載存放庫 (AWR) 報告所回報的計量。 圖表中使用的計量如下所示：

  • 平均 IO 要求數/秒
    對應至負載設定檔區段中平均讀取 IO 要求數/秒和平均寫入 IO 要求數/秒的總和
  • 平均 IO MB/秒
    對應至負載設定檔區段中平均讀取 IO MB/秒和平均寫入 IO MB/秒的總和
  • 讀取延遲的平均值
    對應至 Oracle Wait 事件「db 檔案循序讀取」的平均延遲時間，以微秒為單位
  • 執行緒數目/結構描述
    對應至每個使用者結構描述的 SLOB 執行緒數目

效能測量結果

本節說明效能測量的結果。

Linux kNFS 用戶端與Oracle Direct NFS

此案例執行的是 Azure VM Standard_D32s_v3 (Intel E5-2673 v4 @ 2.30 GHz)。 工作負載為 75% 選取 和 25% 更新，大部分是隨機 I/O，且資料庫緩衝區叫用率約 7.5%。

如下圖所示，Oracle DNFS 用戶端傳遞的輸送量是一般 Linux kNFS 用戶端輸送量 2.8 倍以上：

Linux kNFS 用戶端與 Oracle Direct NFS 的比較

下圖顯示讀取作業的延遲曲線。 在此內容中，kNFS 用戶端的瓶頸是在用戶端與 NFS 伺服器 (Azure NetApp Files 磁碟區) 之間建立的單一 NFS TCP 通訊端連線。

與 Oracle Direct NFS 延遲曲線比較的 Linux kNFS 用戶端

因為 DNFS 用戶端可以建立數百個 TCP 通訊端連線，因此利用平行處理原則，就能推送更多 IO 要求數/秒。 如 Azure NetApp Files 設定所述，配置的容量每多一 TiB 就可以讓頻寬增加 128MiB/秒。 DNFS 的最高輸送量為 1 GiB/秒，這是選擇 8-TiB 容量所帶來的限制。 假設有更多容量，則會驅動更多輸送量。

輸送量只是其中一個考量。 另一個考量是延遲，會對使用者體驗造成主要影響。 如下圖所示，相較於 DNFS，預期 kNFS 的延遲時間增加速度更快。

Linux kNFS 用戶端與 Oracle Direct NFS 讀取延遲比較

長條圖提供資料庫延遲時間的絕佳見解。 下圖從記錄的「db 檔案循序讀取」觀點提供完整的檢視，同時在最高並行資料點上使用 DNFS (32 個執行緒/結構描述)。 如下圖所示，所有讀取作業中有 47% 在 512 微秒到 1000 微秒之間完成，而 90% 的讀取作業在延遲低於 2 毫秒時處理。

Linux kNFS 用戶端與 Oracle Direct NFS 直方圖比較

總之，若要提升 NFS 上 Oracle 資料庫執行個體的效能，顯然 DNFS 是必要條件。

單一磁碟區效能限制

本節說明具有隨機 I/O 和循序 I/O 的單一磁碟區效能限制。

隨機 I/O

DNFS 可以取用的頻寬遠比 8 TB Azure NetApp Files 效能配額所提供的還多。 藉由將 Azure NetApp Files 磁碟區容量增加至 16 TiB (這是瞬間變更)，磁碟區頻寬數量會從 1024 MiB/秒增加 2 倍到 2048 MiB/秒。

下圖顯示 80% 選取和 20% 更新工作負載的設定，以及資料庫緩衝區叫用率為 8%。 SLOB 可以將單一磁碟區推動至每秒 200，000 個 NFS I/O 要求。 考慮到每個作業都是 8 KiB 大小，受測系統可以傳遞每秒約 200，000 個 IO 要求或每秒 1600 MiB。

Oracle DNFS 輸送量

下列讀取延遲曲線圖顯示，當讀取輸送量增加時，延遲會在 1 毫秒線以下緩慢增加，並在平均讀取延遲約 1.3 毫秒、每秒平均讀取 IO 要求數約 165,000 處觸及曲線折角。 這個值是一個不可思議的延遲值，Azure 雲端幾乎沒有任何其他技術可以達成這樣的 I/O 率。

Oracle DNFS 延遲曲線

循序 I/O

如下圖所示，並非所有 I/O 在本質上都是隨機性，請考慮 RMAN 備份或完整資料表掃描，舉例來說，當工作負載需要頻寬越多越好時。 使用先前所述的相同設定，但磁碟區大小調整為 32 TiB，下圖會顯示單一 Oracle DB 執行個體可以向上驅動每秒 3，900 MB 的輸送量，非常接近 Azure NetApp Files 磁碟區的效能配額 32 TB (128 MB/秒 * 32 = 4096 MB/秒)。

Oracle DNFS I/O

總而言之，Azure NetApp Files 可協助您將 Oracle 資料庫移轉到雲端。 它會在資料庫需要時提供效能。 您可以隨時以動態且非中斷方式調整磁碟區配額的大小。

下一步