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

  • 發行項

本文說明有關雲端中 Oracle 的下列主題。 這些主題對資料庫管理員、雲端架構師或記憶體架構師可能特別感興趣：

  • 當您驅動在線事務處理 （OLTP） 工作負載 （大部分為隨機 I/O） 或在線分析處理 （OLAP） 工作負載 （大部分為循序 I/O） 時，效能看起來會是什麼樣子？
  • 一般 Linux 核心 NFS （kNFS） 用戶端和 Oracle 本身的 Direct NFS 用戶端之間的效能有何差異？
  • 就帶寬而言，單一 Azure NetApp Files 磁碟區的效能是否足夠？

重要

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

測試環境和元件

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

Oracle testing environment

虛擬機器組態

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

  • 作業系統：
    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 配置磁碟區容量每 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% SELECT，20% UPDATE |隨機 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% SELECT |循序 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：真
  • 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/秒的總和
  • 平均讀取延遲
    對應至Microseconds中 Oracle Wait 事件「db 檔案循序讀取」的平均延遲
  • 線程/架構的數目
    對應至每個用戶架構的 SLOB 線程數目

效能測量結果

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

Linux kNFS 用戶端與 Oracle Direct NFS

此案例是在 Azure VM Standard_D32s_v3上執行（Intel E5-2673 v4 @ 2.30 GHz）。 工作負載是 75% SELECT 和 25% UPDATE，大部分是隨機 I/O，且資料庫緩衝區達到 ~7.5%。

如下圖所示，Oracle DNFS 用戶端的輸送量比一般 Linux kNFS 用戶端多 2.8 倍：

Linux kNFS Client compared with Oracle Direct NFS

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

Linux kNFS Client compared with Oracle Direct NFS latency curve

DNFS 用戶端能夠推送更多 IO 要求/秒，因為它能夠建立數百個 TCP 套接字連線，因此會利用平行處理原則。 如 Azure NetApp Files 設定中所述，配置的每個額外容量 TiB 都允許額外的 128MiB/秒頻寬。 DNFS 達到 1 GiB/秒的輸送量，這是 8 TiB 容量選取所加總的限制。 假設有更多容量，則會驅動更多輸送量。

輸送量只是其中一個考慮。 另一個考慮是延遲，這對用戶體驗有主要影響。 如下圖所示，KNFS 的延遲增加速度可能會比使用 DNFS 快得多。

Linux kNFS Client compared with Oracle Direct NFS read latency

直方圖可讓您深入了解資料庫延遲。 下圖提供完整檢視，從記錄的「資料庫檔案循序讀取」的觀點，同時在最高的並行數據點使用 DNFS（32 個線程/架構）。 如下圖所示，在 512 微秒和 1000 微秒之間，47% 的所有讀取作業都會接受，而 90% 的所有讀取作業會在低於 2 毫秒的延遲下提供服務。

Linux kNFS Client compared with Oracle Direct NFS histograms

最後，很明顯，DNFS 是改善 NFS 上 Oracle 資料庫實例效能時必須具備的。

單一磁碟區效能限制

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

隨機 I/O

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

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

Oracle DNFS throughput

下列讀取延遲曲線圖顯示，當讀取輸送量增加時，延遲會在 1 毫秒線以下順暢地增加，而且會在 ~165,000 平均讀取 IO 要求/秒的曲線膝蓋達到 ~1.3 毫秒的平均讀取延遲。 此值對於幾乎 Azure 雲端中任何其他技術而言，I/O 速率是難以置信的延遲值。

Oracle DNFS latency curve

循序 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 資料庫帶到雲端。 當資料庫要求時，它會提供效能。 您可以隨時動態且不干擾地調整磁碟區配額的大小。

下一步