Prestanda för Oracle-databas på enskilda Azure NetApp-volymer

  • Artikel

I den här artikeln beskrivs följande avsnitt om Oracle i molnet. Dessa ämnen kan vara av särskilt intresse för en databasadministratör, molnarkitekt eller lagringsarkitekt:

  • Hur ser prestanda ut när du kör en arbetsbelastning för onlinetransaktionsbearbetning (OLTP) (mestadels slumpmässig I/O) eller en arbetsbelastning för onlineanalysbearbetning (OLAP) (mestadels sekventiell I/O) ?
  • Vad är skillnaden i prestanda mellan den vanliga Linux Kernel NFS-klienten (kNFS) och Oracles egen Direct NFS-klient?
  • Räcker det med prestanda för en enda Azure NetApp Files-volym när det gäller bandbredd?

Viktigt!

För korrekt och optimal distribution av Orace dNFS följer du riktlinjerna för korrigering som beskrivs här.

Testa miljö och komponenter

Följande diagram illustrerar den miljö som används för testning. För konsekvens och enkelhet användes Ansible-spelböcker för att distribuera alla delar av testbädden.

Oracle testing environment

Konfiguration av virtuell dator

Testerna använde följande konfiguration för den virtuella datorn:

  • Operativsystem:
    RedHat Enterprise Linux 7.8 (wle-ora01)
  • Instanstyper:
    Två modeller användes vid testning – D32s_v3 och D64s_v3
  • Antal nätverksgränssnitt:
    En (1) placerad i undernät 3
  • Diskar:
    Oracle-binärfiler och operativsystem placerades på en enda Premium-disk

Konfiguration av Azure NetApp Files

Testerna använde följande Azure NetApp Files-konfiguration:

  • Kapacitetspoolens storlek:
    Olika storlekar på poolen konfigurerades: 4 TiB, 8 TiB, 16 TiB, 32 TiB
  • Tjänstnivå:
    Ultra (128 MiB/s bandbredd per 1 TiB allokerad volymkapacitet)
  • Volymer:
    Ett och två volymtester utvärderades

Arbetsbelastningsgenerator

Testerna använde arbetsbelastningen genererade SLOB 2.5.4.2. SLOB (Silly Little Oracle Benchmark) är en välkänd arbetsbelastningsgenerator i Oracle-utrymmet som är utformat för att stressa och testa I/O-undersystemet med en SGA-buffrad fysisk I/O-arbetsbelastning.

SLOB 2.5.4.2 stöder inte den pluggbara databasen (PDB). Därför lades en ändring till i skripten setup.sh och runit.sh för att lägga till PDB-stöd till den.

De SLOB-variabler som används i testerna beskrivs i följande avsnitt.

Arbetsbelastning 80 % SELECT, 20 % UPPDATERING | Slumpmässig I/O – slob.conf variabler

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

Arbetsbelastning 100 % SELECT | Sekventiell I/O – slob.conf variabler

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

Databas

Oracle-versionen som används för testerna är Oracle Database Enterprise Edition 19.3.0.0.

Oracle-parametrarna är följande:

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

En PDB skapades för SLOB-databasen.

Följande diagram visar tabellområdet med namnet PERFIO med 600 GB i storlek (20 datafiler, 30 GB vardera) som skapats som värd för fyra SLOB-användarscheman. Varje användarschema var 125 GB stort.

Oracle database

Prestandamått

Målet var att rapportera I/O-prestanda enligt programmets erfarenhet. Därför använder alla diagram i den här artikeln mått som rapporterats av Oracle-databasen via AWR-rapporter (Automatic Workload Repository). Måtten som används i diagrammen är följande:

  • Genomsnittliga I/O-begäranden per sekund
    Motsvarar summan av genomsnittliga läs-I/O-begäranden per sekund och genomsnittliga I/O-skrivbegäranden per sekund från avsnittet för belastningsprofil
  • Genomsnittlig I/O MB/s
    Motsvarar summan av genomsnittlig läs-I/O MB/s och genomsnittlig I/O MB/s för skrivning från avsnittet belastningsprofil
  • Genomsnittlig svarstid för läsning
    Motsvarar den genomsnittliga svarstiden för Oracle Wait Event "db file sekventiell läsning" i mikrosekunder
  • Antal trådar/schema
    Motsvarar antalet SLOB-trådar per användarschema

Resultat av prestandamätning

I det här avsnittet beskrivs resultatet av prestandamätning.

Linux kNFS-klient jämfört med Oracle Direct NFS

Det här scenariot kördes på en virtuell Azure-dator Standard_D32s_v3 (Intel E5-2673 v4 @ 2,30 GHz). Arbetsbelastningen är 75 % SELECT och 25 % UPDATE, mestadels slumpmässig I/O, och med en databasbuffert på ~7,5 %.

Som visas i följande diagram levererade Oracle DNFS-klienten upp till 2,8 x mer dataflöde än den vanliga Linux kNFS-klienten:

Linux kNFS Client compared with Oracle Direct NFS

Följande diagram visar svarstidskurvan för läsåtgärderna. I det här sammanhanget är flaskhalsen för kNFS-klienten den enda NFS TCP-socketanslutningen som upprättats mellan klienten och NFS-servern (Azure NetApp Files-volymen).

Linux kNFS Client compared with Oracle Direct NFS latency curve

DNFS-klienten kunde skicka fler I/O-begäranden per sekund på grund av dess möjlighet att skapa hundratals TCP-socketanslutningar, och därmed dra nytta av parallelliteten. Enligt beskrivningen i Azure NetApp Files-konfigurationen möjliggör varje ytterligare TiB av allokerad kapacitet ytterligare 128MiB/s bandbredd. DNFS toppade med 1 GiB/s dataflöde, vilket är den gräns som införts av valet av 8-TiB-kapacitet. Med tanke på mer kapacitet skulle mer dataflöde ha drivits.

Dataflödet är bara ett av övervägandena. Ett annat övervägande är svarstid, vilket har den primära effekten på användarupplevelsen. Som följande diagram visar kan svarstidsökningar förväntas mycket snabbare med kNFS än med DNFS.

Linux kNFS Client compared with Oracle Direct NFS read latency

Histogram ger utmärkt insikt i databasfördröjningar. Följande diagram ger en fullständig vy från perspektivet av den inspelade "db-filen sekventiell läsning", medan du använder DNFS på den högsta samtidighetsdatapunkten (32 trådar/schema). Som du ser i följande diagram har 47 % av alla läsåtgärder respekterats mellan 512 mikrosekunder och 1 000 mikrosekunder, medan 90 % av alla läsåtgärder har hanterats med en svarstid under 2 ms.

Linux kNFS Client compared with Oracle Direct NFS histograms

Sammanfattningsvis är det tydligt att DNFS är ett måste när det gäller att förbättra prestanda för en Oracle-databasinstans på NFS.

Prestandabegränsningar för enskilda volymer

I det här avsnittet beskrivs prestandagränserna för en enskild volym med slumpmässig I/O och sekventiell I/O.

Slumpmässig I/O

DNFS kan använda mycket mer bandbredd än vad som tillhandahålls av en prestandakvot på 8 TB i Azure NetApp Files. Genom att öka Volymkapaciteten för Azure NetApp Files till 16 TiB, vilket är en omedelbar förändring, ökade mängden volymbandbredd från 1 024 MiB/s med 2X till 2 048 MiB/s.

Följande diagram visar en konfiguration för en arbetsbelastning på 80 % och en uppdateringsarbetsbelastning på 20 % och med en databasbuffert på 8 %. SLOB kunde köra en enskild volym till 200 000 NFS I/O-begäranden per sekund. Med tanke på att varje åtgärd är 8-KiB-storlek kunde systemet som testas leverera ~200 000 I/O-begäranden per sekund eller 1 600 MiB/s.

Oracle DNFS throughput

Följande diagram över lässvarstidskurvan visar att svarstiden ökar smidigt under linjen 1 ms, och den träffar knät på kurvan vid ~165 000 genomsnittliga läs-I/O-begäranden/s med den genomsnittliga läsfördröjningen på ~1,3 ms. Det här värdet är ett otroligt svarstidsvärde för en I/O-hastighet som inte kan uppnås med nästan all annan teknik i Azure Cloud.

Oracle DNFS latency curve

Sekventiell I/O

Som du ser i följande diagram är inte alla I/O slumpmässiga, med tanke på en RMAN-säkerhetskopiering eller en fullständig tabellgenomsökning, till exempel som arbetsbelastningar som kräver så mycket bandbredd som de kan få. Med samma konfiguration som beskrivits tidigare, men med volymen ändrad till 32 TiB, visar följande diagram att en enskild Oracle DB-instans kan köra uppemot 3 900 MB/s dataflöde, mycket nära Azure NetApp Files-volymens prestandakvot på 32 TB (128 MB/s * 32 = 4 096 MB/s).

Oracle DNFS I/O

Sammanfattningsvis hjälper Azure NetApp Files dig att ta dina Oracle-databaser till molnet. Det ger prestanda när databasen kräver det. Du kan dynamiskt och icke-störande ändra storlek på volymkvoten när som helst.

Nästa steg