Azure NetApp Files の単一ボリュームでの Oracle データベースのパフォーマンスOracle database performance on Azure NetApp Files single volumes

この記事では、クラウドにおける Oracle に関する次のトピックについて説明します。This article addresses the following topics about Oracle in the cloud. これらのトピックは、データベース管理者、クラウド アーキテクト、またはストレージ アーキテクトに特に関係があります。These topics might be of particular interest to a database administrator, cloud architect, or storage architect:

  • オンライン トランザクション処理 (OLTP) ワークロード (ほとんどがランダム I/O) またはオンライン分析処理 (OLAP) ワークロード (ほとんどがシーケンシャル I/O) を処理する場合、パフォーマンスはどのようになるか。When you drive an online transaction processing (OLTP) workload (mostly random I/O) or an online analytical processing (OLAP) workload (mostly sequential I/O), what does performance look like?
  • 通常の Linux カーネル NFS (kNFS) クライアントと Oracle 独自の Direct NFS クライアントではパフォーマンスはどのように異なるか。What is the difference in performance between the regular Linux kernel NFS (kNFS) client and Oracle’s own Direct NFS client?
  • 帯域幅に関して、1 つの Azure NetApp Files ボリュームのパフォーマンスで十分か。As far as bandwidth is concerned, is the performance of a single Azure NetApp Files volume enough?

テスト環境とコンポーネントTesting environment and components

次の図は、テストに使用された環境を示しています。The following diagram illustrates the environment used for testing. 一貫性と簡潔さを実現するために、テスト ベッドのすべての要素をデプロイするために、Ansible プレイブックを使用しました。For consistency and simplicity, Ansible playbooks were used to deploy all elements of the test bed.

Oracle テスト環境

仮想マシンの構成Virtual machine configuration

テストでは、仮想マシンに対して次のセットアップを使用しました。The tests used the following setup for the virtual machine:

  • オペレーティング システム:Operating system:
    RedHat Enterprise Linux 7.8 (wle-ora01)RedHat Enterprise Linux 7.8 (wle-ora01)
  • インスタンスの種類:Instance types:
    テストでは 2 つのモデル(D32s_v3 と D64s_v3)を使用Two models were used in testing – D32s_v3 and D64s_v3
  • ネットワーク インターフェイスの数:Network interface count:
    サブネット 3 に 1 つ配置One (1) placed in subnet 3
  • ディスク:Disks:
    Oracle バイナリと OS を 1 つの Premium ディスクに配置Oracle binaries and OS were placed in a single premium disk

Azure NetApp Files 構成Azure NetApp Files configuration

テストでは、次の Azure NetApp Files 構成を使用しました。The tests used the following Azure NetApp Files configuration:

  • 容量プール サイズ:Capacity pool size:
    さまざまなサイズのプールを構成:4 TiB、8 TiB、16 TiB、32 TiBVarious sizes of the pool were configured: 4 TiB, 8 TiB, 16 TiB, 32 TiB
  • サービス レベル:Service level:
    Ultra (割り当て済みボリューム容量 1 TiB ごとに帯域幅 128 MiB/s)Ultra (128 MiB/s of bandwidth per 1 TiB of allocated volume capacity)
  • ボリューム:Volumes:
    1 つおよび 2 つのボリュームのテストを評価One and two volume tests were evaluated

ワークロード ジェネレーターWorkload generator

テストでは、ワークロード ジェネレーター SLOB 2.5.4.2 を使用しました。The tests used workload generated SLOB 2.5.4.2. SLOB (Silly Little Oracle Benchmark) は、SGA バッファの物理 I/O ワークロードを使用して、I/O サブシステムに負荷をかけてテストすることを目的とした、Oracle スペースでよく知られているワークロード ジェネレーターです。SLOB (Silly Little Oracle Benchmark) is a well-known workload generator in the Oracle space designed to stress and test the I/O subsystem with an SGA-buffered physical I/O workload.

SLOB 2.5.4.2 では、プラグ可能なデータベース (PDB) はサポートされていません。SLOB 2.5.4.2 does not support the pluggable database (PDB). そのため、PDB サポートを追加するために、setup.sh および runit.sh のスクリプトに変更を加えました。As such, a change was added to the setup.sh and runit.sh scripts to add PDB support to it.

以下のセクションで、このテストで使用した SLOB 変数について説明します。The SLOB variables used in the tests are described in the following sections.

ワークロード: 80% SELECT、20% UPDATE | ランダム I/O - slob.conf 変数Workload 80% SELECT, 20% UPDATE | Random I/O – slob.conf variables

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 変数Workload 100% SELECT | Sequential I/O – slob.conf variables

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 です。The Oracle version used for the tests is Oracle Database Enterprise Edition 19.3.0.0.

Oracle パラメーターは、次のとおりです。The Oracle parameters are as follows:

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

SLOB データベースの PDB が作成されました。A PDB was created for the SLOB database.

次の図は、4つの SLOB ユーザー スキーマをホストするために作成された PERFIO という名前の 600 GB のサイズ (それぞれ 30 GB の 20 個のデータ ファイル) の名前空間を示しています。The following diagram shows the tablespace named PERFIO with 600 GB in size (20 data files, 30 GB each) created to host four SLOB user schemas. 各ユーザー スキーマのサイズは 125 GB でした。Each user schema was 125 GB in size.

Oracle データベース

パフォーマンス メトリックPerformance metrics

目標は、アプリケーションで見られた IO パフォーマンスを報告することでした。The goal was to report the IO performance as experienced by the application. したがって、この記事のすべての図では、Oracle データベースによって、その Automatic Workload Repository (AWR) レポートで報告されたメトリックが使用されています。Therefore, all diagrams in this article use metrics reported by the Oracle database via its Automatic Workload Repository (AWR) reports. 図で使用されるメトリックは次のとおりです。The metrics used in the diagrams are as follows:

  • Average IO Requests/sec (平均 IO 要求数/秒) Average IO Requests/sec
    プロファイルの読み込みセクションからの平均読み取り IO 要求数/秒と平均書き込み IO 要求数/秒の合計に対応しますCorresponds to the sum of average Read IO Requests/sec and average Write IO Requests/sec from the load profile section
  • Average IO MB/sec (平均 IO MB/秒) Average IO MB/sec
    プロファイルの読み込みセクションからの平均読み取り IO MB/秒と平均書き込み IO MB/秒の合計に対応しますCorresponds to the sum of average Read IO MB/sec and average Write IO MB/sec from the load profile section
  • Average Read latency (読み取りの平均待機時間) Average Read latency
    Oracle Wait イベントの "db file sequential read" (db ファイルの順次読み取り) の平均待機時間 (マイクロ秒) に対応しますCorresponds to the average latency of the Oracle Wait Event “db file sequential read” in microseconds
  • Number of threads/schema (スキーマあたりのスレッド数) Number of threads/schema
    ユーザー スキーマあたりの SLOB スレッド数に対応しますCorresponds to the number of SLOB threads per user schema

パフォーマンス測定の結果Performance measurement results

このセクションでは、パフォーマンス測定の結果について説明します。This section describes the results of performance measurement.

Linux kNFS クライアントと Oracle Direct NFS の比較Linux kNFS Client vs. Oracle Direct NFS

このシナリオは、Azure VM Standard_D32s_v3 (2.30 GHz の Intel E5-2673 v4) で実行されました。This scenario was running on an Azure VM Standard_D32s_v3 (Intel E5-2673 v4 @ 2.30 GHz). ワークロードは、75% が SELECT で 25% が UPDATE (ほとんどがランダム I/O) であり、データベース バッファーのヒットは約 7.5% です。The workload is 75% SELECT and 25% UPDATE, mostly random I/O, and with a database buffer hit of ~7.5%.

次の図に示すように、Oracle DNFS クライアントは、通常の Linux kNFS クライアントの最大 2.8 倍のスループットを提供しています。As shown in the following diagram, the Oracle DNFS client delivered up to 2.8x more throughput than the regular Linux kNFS Client:

Linux kNFS クライアントと Oracle Direct NFS の比較

次の図は、読み取り操作の待機時間曲線を示しています。The following diagram shows the latency curve for the read operations. このコンテキストでは、kNFS クライアントのボトルネックは、クライアントと NFS サーバー (Azure NetApp Files ボリューム) の間に確立される単一の NFS TCP ソケット接続です。In this context, the bottleneck for the kNFS client is the single NFS TCP socket connection established between the client and the NFS server (the Azure NetApp Files volume).

Linux kNFS クライアントと Oracle Direct NFS の待機時間曲線の比較

DNFS クライアントは、数百の TCP ソケット接続を作成できるため 1 秒あたりの IO 要求のプッシュ回数が増加しました。このため、並列処理の利点を活用できます。The DNFS client was able to push more IO requests/sec due to its ability to create hundreds of TCP socket connections, therefore taking advantage of the parallelism. Azure NetApp Files 構成」で説明されているように、容量を 1 TiB 追加で割り当てるごとに、128 MiB/秒の帯域幅を追加できます。As described in Azure NetApp Files configuration, each additional TiB of capacity allocated allows for an additional 128MiB/s of bandwidth. DNFS のスループットは 1 GiB/秒で頭打ちとなります。これは 8 TiB の容量選択によって課される制限です。DNFS topped out at 1 GiB/s of throughput, which is the limit imposed by the 8-TiB capacity selection. 容量を増やすと、より多くのスループットが得られます。Given more capacity, more throughput would have been driven.

スループットは考慮事項の 1 つにすぎません。Throughput is only one of the considerations. もう 1 つの考慮事項は、ユーザー エクスペリエンスに大きな影響を与える待機時間です。Another consideration is latency, which has the primary impact on user experience. 次の図に示すように、kNFS の方が DNFS よりも、待機時間の急激な増加が予想されます。As the following diagram shows, latency increases can be expected far more rapidly with kNFS than with DNFS.

Linux kNFS クライアントと Oracle Direct NFS の読み取り待機時間の比較

ヒストグラムは、データベースの待機時間に関する優れた洞察を提供します。Histograms provide excellent insight into database latencies. 次の図は、最大の同時実行データ ポイント (32 スレッド/スキーマ) で DNFS を使用したときの、記録された "db file sequential read"(db ファイルの順次読み取り) の観点から見た完全なビューを示しています。The following diagram provides a complete view from the perspective of the recorded "db file sequential read", while using DNFS at the highest concurrency data point (32 threads/schema). 次の図に示すように、全読み取り操作の 47% が 512 マイクロ秒と 1000 マイクロ秒の間で処理され、全読み取り操作の 90% が 2 ミリ秒未満の待機時間で処理されました。As shown in the following diagram, 47% of all read operations were honored between 512 microseconds and 1000 microseconds, while 90% of all read operations were served at a latency below 2 ms.

Linux kNFS クライアントと Oracle Direct NFS のヒストグラムの比較

結論としては明らかなのは、NFS で Oracle データベース インスタンスのパフォーマンスを向上させるには DNFS が必要であるということです。In conclusion, it's clear that DNFS is a must-have when it comes to improving the performance of an Oracle database instance on NFS.

単一ボリュームのパフォーマンス制限Single volume performance limits

このセクションでは、ランダム I/O とシーケンシャル I/O を使用した単一ボリュームのパフォーマンスの制限について説明します。This section describes the performance limits of a single volume with random I/O and sequential I/O.

ランダム I/ORandom I/O

DNFS は、Azure NetApp Files の 8 TB のパフォーマンス クォータによって提供されるものよりもはるかに広い帯域幅を消費できます。DNFS is capable of consuming far more bandwidth than what is provided by an 8-TB Azure NetApp Files performance quota. Azure NetApp Files ボリューム容量を 16 TiB に増やすことで (これは瞬時に変更されます)、ボリューム帯域幅の量は 1024 MiB/秒から 2 倍の 2048 MiB/秒に増加しました。By increasing the Azure NetApp Files volume capacity to 16 TiB, which is an instantaneous change, the amount of volume bandwidth increased from 1024 MiB/s by 2X to 2048 MiB/s.

次の図は、80% の SELECT および 20% の UPDATE のワークロードで、データベース バッファーのヒット率が 8% の構成を示しています。The following diagram shows a configuration for an 80% select and 20% update workload, and with a database buffer hit ratio of 8%. SLOB では、単一ボリュームで 1 秒間に 20 万 NFS I/O 要求まで実行することができました。SLOB was able to drive a single volume to 200,000 NFS I/O requests per second. 各操作が 8 KiB のサイズであることを考慮すると、テスト対象のシステムでは、1 秒間に約 20 万 IO 要求/秒または 1600 MiB/秒を処理できました。Considering that each operation is 8-KiB size, the system under test was able to deliver ~200,000 IO requests/sec or 1600 MiB/s.

Oracle DNFS のスループット

次の読み取り待機時間曲線図は、読み取りスループットが増加するにつれて、待機時間が 1 ミリ秒未満で緩やかに増加し、1 秒間の平均読み取り IO 要求数が約 165,000 で、平均読み取り待機時間が約 1.3 ミリ秒のときに、曲線の急な折れ曲がりに達したことを示しています。The following read latency curve diagram shows that, as the read throughput increases, the latency increases smoothly below the 1-ms line, and it hits the knee of the curve at ~165,000 average read IO requests/sec at the average read latency of ~1.3 ms. この値は、Azure Cloud の他のほとんどすべてのテクノロジで実現できない I/O レートでの優れた待機時間値です。This value is an incredible latency value for an I/O rate unachievable with almost any other technology in the Azure Cloud.

Oracle DNFS の待機時間曲線

シーケンシャル I/OSequential I/O

たとえば RMAN バックアップまたはフル テーブル スキャンを、できるだけ多くの帯域幅を必要とするワークロードとみなした場合、次の図に示すように、すべての I/O がランダムであるとは限りません。As shown in the following diagram, not all I/O is random in nature, considering an RMAN backup or a full table scan, for example, as workloads requiring as much bandwidth as they can get. 前に説明したのと同じ構成を、ボリュームのサイズを 32 TiB に変更して使用した場合、次の図は、1 つの Oracle DB インスタンスが 3900 MB/秒のスループットを超えていることを示しており、これは Azure NetApp Files ボリュームの 32 TB のパフォーマンス クォータ (128 MB/秒 * 32 = 4096 MB/秒) に非常に近いものです。Using the same configuration as described previously but with the volume resized to 32 TiB, the following diagram shows that a single Oracle DB instance can drive upwards of 3,900 MB/s of throughput, very close to the Azure NetApp Files volume's performance quota of 32 TB (128 MB/s * 32 = 4096 MB/s).

Oracle DNFS の I/O

要約すると、Azure NetApp Files は Oracle データベースをクラウドに移行するのに役立ちます。In summary, Azure NetApp Files helps you take your Oracle databases to the cloud. これにより、データベースが要求したときにパフォーマンスが提供されます。It delivers on performance when the database demands it. ボリューム クォータのサイズは、動的に、かつ中断することなく、いつでも変更できます。You can dynamically and non-disruptively resize your volume quota at any time.

次のステップNext steps