Performa database Oracle pada volume tunggal Azure NetApp Files

Artikel ini membahas topik-topik berikut tentang Oracle di cloud. Topik-topik ini mungkin menarik bagi administrator database, arsitek cloud, atau arsitek penyimpanan:

• Ketika Anda mendorong beban kerja pemrosesan transaksi online (OLTP) (sebagian besar I/O acak) atau beban kerja pemrosesan analitik online (OLAP) (sebagian besar I/O berurutan), bagaimana performanya?
• Apa perbedaan performa antara klien Linux kernel NFS (kNFS) reguler dan klien Direct NFS Oracle sendiri?
• Berkaitan dengan bandwidth, apakah performa satu volume Azure NetApp Files cukup besar?

Penting

Untuk penyebaran Orace dNFS yang benar dan optimal, ikuti panduan patching yang diuraikan di sini.

Lingkungan dan komponen pengujian

Diagram berikut mengilustrasikan lingkungan yang digunakan untuk pengujian. Untuk konsistensi dan kesederhanaan, playbook Ansible digunakan untuk menyebarkan semua elemen tempat tidur pengujian.

Konfigurasi komputer virtual

Pengujian ini menggunakan pengaturan berikut untuk komputer virtual:

• Sistem operasi:
  RedHat Enterprise Linux 7.8 (wle-ora01)
• Jenis instans:
  Dua model digunakan dalam pengujian - D32s_v3 dan D64s_v3
• Jumlah antarmuka jaringan:
  Satu (1) ditempatkan di subnet 3
• Disk:
  Biner dan OS Oracle ditempatkan dalam satu disk premium

Konfigurasi Azure NetApp Files

Pengujian menggunakan konfigurasi Azure NetApp Files berikut:

• Ukuran kumpulan kapasitas:
  Berbagai ukuran kumpulan dikonfigurasi: 4 TiB, 8 TiB, 16 TiB, 32 TiB
• Tingkat layanan:
  Ultra (bandwidth 128 MiB/dtk per 1 TiB kapasitas volume yang dialokasikan)
• Volume:
  Satu dan dua pengujian volume dievaluasi

Generator beban kerja

Pengujian menggunakan beban kerja yang dihasilkan SLOB 2.5.4.2. SLOB (Silly Little Oracle Benchmark) adalah generator beban kerja terkenal di ruang Oracle yang dirancang untuk menekan dan menguji subsistem I/O dengan beban kerja I/O fisik yang di-buffer SGA.

SLOB 2.5.4.2 tidak mendukung database yang dapat dicolokkan (PDB). Dengan demikian, perubahan ditambahkan ke skrip setup.sh dan runit.sh untuk menambahkan dukungan PDB ke dalamnya.

Variabel SLOB yang digunakan dalam pengujian dijelaskan di bagian berikut.

Beban kerja 80% SELECT, 20% UPDATE | I/O acak – slob.conf variabel

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

Beban kerja 100% SELECT | I/O berurutan – slob.conf variabel

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

Versi Oracle yang digunakan untuk pengujian adalah Oracle Database Enterprise Edition 19.3.0.0.

Parameter Oracle adalah sebagai berikut:

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

Satu PDB dibuat untuk database SLOB.

Diagram berikut menunjukkan ruang tabel bernama PERFIO dengan ukuran 600 GB (20 file data, masing-masing berukuran 30 GB) dibuat untuk menghosting empat skema pengguna SLOB. Setiap skema pengguna berukuran 125 GB.

Metrik performa

Tujuannya adalah melaporkan performa IO seperti yang dialami oleh aplikasi. Oleh karena itu, semua diagram dalam artikel ini menggunakan metrik yang dilaporkan oleh database Oracle melalui laporan Repositori Beban Kerja Otomatis (AWR). Metrik yang digunakan dalam diagram adalah sebagai berikut:

• Rata-rata Permintaan IO/detik
  Sesuai dengan jumlah rata-rata Baca Permintaan IO/detik dan rata-rata Tulis Permintaan IO/detik dari bagian profil beban
• Rata-rata IO MB/detik
  Sesuai dengan jumlah rata-rata Baca IO MB/detik dan rata-rata Tulis IO MB/detik dari bagian profil beban
• Rata-rata latensi Baca
  Sesuai dengan latensi rata-rata Peristiwa Tunggu Oracle "file db yang dibaca berurutan" dalam mikrodetik
• Jumlah thread/skema
  Sesuai dengan jumlah thread SLOB per skema pengguna

Hasil pengukuran performa

Bagian ini menjelaskan hasil pengukuran performa.

Klien kNFS Linux vs. Oracle Direct NFS

Skenario ini berjalan pada Azure VM Standard_D32s_v3 (Intel E5-2673 v4 @ 2,30 GHz). Beban kerjanya adalah 75% SELECT dan 25% UPDATE, sebagian besar I/O acak, dan dengan hit buffer database ~ 7,5%.

Seperti yang ditunjukkan dalam diagram berikut, klien Oracle DNFS mengirimkan throughput hingga 2,8x lebih banyak daripada Klien kNFS Linux reguler:

Diagram berikut menunjukkan kurva latensi untuk operasi baca. Dalam konteks ini, hambatan untuk klien kNFS adalah koneksi soket NFS TCP tunggal yang dibuat antara klien dan server NFS (volume Azure NetApp Files).

Klien DNFS mampu mendorong lebih banyak permintaan IO/detik karena kemampuannya untuk membuat ratusan koneksi soket TCP, sehingga mengambil keuntungan dari paralelisme. Seperti yang dijelaskan dalam konfigurasi Azure NetApp Files, setiap TiB kapasitas tambahan yang dialokasikan memungkinkan bandwidth tambahan sebesar 128MiB/dtk. DNFS menduduki puncak pada 1 GiB/dtk throughput, yaitu batas yang diberlakukan oleh pilihan kapasitas 8-TiB. Jika ada lebih banyak kapasitas, akan lebih banyak throughput yang akan didorong.

Throughput hanyalah salah satu pertimbangan. Pertimbangan lainnya adalah latensi, yang memiliki dampak utama pada pengalaman pengguna. Seperti yang ditunjukkan diagram berikut, peningkatan latensi dapat diharapkan jauh lebih cepat dengan kNFS daripada dengan DNFS.

Histogram memberikan wawasan yang sangat baik tentang latensi database. Diagram berikut memberikan tampilan lengkap dari perspektif "file db yang dibaca berurutan" yang direkam, saat menggunakan DNFS pada poin data konkurensi tertinggi (32 thread/skema). Seperti yang ditunjukkan dalam diagram berikut, 47% dari semua operasi baca dijalankan antara 512 mikrodetik dan 1000 mikrodetik, sementara 90% dari semua operasi baca terjadi pada latensi di bawah 2 md.

Kesimpulannya, jelas bahwa DNFS adalah prioritas utama dalam meningkatkan performa instans database Oracle di NFS.

Batas performa volume tunggal

Bagian ini menjelaskan batas performa dari satu volume dengan I/O acak dan I/O berurutan.

I/O acak

DNFS mampu mengonsumsi jauh lebih banyak bandwidth daripada yang disediakan oleh kuota performa Azure NetApp Files sebesar 8 TB. Dengan meningkatkan kapasitas volume Azure NetApp Files menjadi 16 TiB, yang merupakan perubahan seketika, jumlah bandwidth volume meningkat 2X lipat dari 1024 MiB/dtk menjadi 2048 MiB/dtk.

Diagram berikut menunjukkan konfigurasi untuk 80% SELECT dan beban kerja 20% UPDATE, dengan rasio klik buffer database 8%. SLOB mampu mendorong satu volume ke 200.000 permintaan I/O NFS per detik. Mengingat bahwa setiap operasi berukuran 8-KiB, sistem yang sedang diuji mampu memberikan ~200.000 permintaan IO/detik atau 1600 MiB/dtk.

Diagram kurva latensi baca berikut menunjukkan bahwa, ketika throughput baca meningkat, latensinya meningkat dengan lancar di bawah garis 1 md, dan menyentuh bagian bawah kurva pada ~165.000 rata-rata baca permintaan IO/detik pada rata-rata latensi baca ~1,3 md. Nilai ini adalah nilai latensi yang luar biasa untuk tingkat I/O yang tidak dapat dicapai dengan hampir semua teknologi lain di Azure Cloud.

IO berurutan

Seperti yang ditunjukkan dalam diagram berikut, tidak semua I/O bersifat acak, mengingat cadangan RMAN atau pemindaian tabel penuh, misalnya, karena beban kerja membutuhkan bandwidth sebanyak mungkin. Dengan menggunakan konfigurasi yang sama seperti yang dijelaskan sebelumnya tetapi dengan volume yang ukurannya diubah menjadi 32 TiB, diagram berikut menunjukkan bahwa satu instans Oracle DB dapat mendorong ke atas 3.900 MB/dtk throughput, sangat dekat dengan kuota performa volume Azure NetApp Files sebesar 32 TB (128 MB/dtk * 32 = 4096 MB/dtk).

Singkatnya, Azure NetApp Files membantu Anda menghadirkan database Oracle Anda ke cloud. Azure NetApp Files memberikan performa ketika database menuntutnya. Anda dapat mengubah ukuran kuota volume secara dinamis dan tidak mengganggu kapan saja.

Langkah berikutnya

• Rekomendasi pengujian tolok ukur performa untuk Azure NetApp Files
• Tolok ukur performa untuk Linux