Oracle-databaseprestaties in afzonderlijke Azure NetApp Files-volumes
In dit artikel worden de volgende onderwerpen behandeld over Oracle in de cloud. Deze onderwerpen zijn mogelijk van bijzonder belang voor een databasebeheerder, cloudarchitect of opslagarchitect:
- Wanneer u een OLTP-workload (Online Transaction Processing) (meestal willekeurige I/O) of een OLAP-workload (online analytical processing) (voornamelijk sequentiële I/O) aangedreven, hoe zien de prestaties eruit?
- Wat is het verschil in prestaties tussen de reguliere Linux-kernel NFS-client (kNFS) en de eigen Direct NFS-client van Oracle?
- Wat de bandbreedte betreft, zijn de prestaties van één Azure NetApp Files-volume voldoende?
Belangrijk
Voor de juiste en optimale implementatie van Orace dNFS volgt u de richtlijnen voor patches die hier worden beschreven.
Testomgeving en onderdelen
In het volgende diagram ziet u de omgeving die wordt gebruikt voor het testen. Voor consistentie en eenvoud werden Ansible-playbooks gebruikt om alle elementen van het testbed te implementeren.
De configuratie van virtuele machines
De tests hebben de volgende installatie voor de virtuele machine gebruikt:
- Besturingssysteem:
RedHat Enterprise Linux 7.8 (wle-ora01) - Instantietypen:
Er zijn twee modellen gebruikt bij het testen: D32s_v3 en D64s_v3 - Aantal netwerkinterfaces:
Eén (1) geplaatst in subnet 3 - Schijven:
Binaire Oracle-bestanden en -besturingssysteem zijn op één Premium-schijf geplaatst
Azure NetApp Files-configuratie
De tests hebben de volgende Configuratie van Azure NetApp Files gebruikt:
- Grootte van capaciteitspool:
Verschillende grootten van het zwembad zijn geconfigureerd: 4 TiB, 8 TiB, 16 TiB, 32 TiB - Serviceniveau:
Ultra (128 MiB/s bandbreedte per 1 TiB van toegewezen volumecapaciteit) - Volumes:
Er zijn één en twee volumetests geëvalueerd
Workloadgenerator
De tests gebruikten de door de workload gegenereerde SLOB 2.5.4.2. SLOB (Silly Little Oracle Benchmark) is een bekende workloadgenerator in de Oracle-ruimte die is ontworpen om het I/O-subsysteem te benadrukken en te testen met een fysieke I/O-workload met SGA-buffer.
SLOB 2.5.4.2 biedt geen ondersteuning voor de pluggable database (PDB). Als zodanig is er een wijziging toegevoegd aan de setup.sh en runit.sh scripts om PDB-ondersteuning eraan toe te voegen.
De SLOB-variabelen die in de tests worden gebruikt, worden beschreven in de volgende secties.
Workload 80% SELECT, 20% UPDATE | Willekeurige I/O - slob.conf variabelen
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
Workload 100% SELECT | Sequentiële I/O – slob.conf variabelen
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
De Oracle-versie die wordt gebruikt voor de tests is Oracle Database Enterprise Edition 19.3.0.0.
De Oracle-parameters zijn als volgt:
sga_max_size: 4096Msga_target: 4096db_writer_processes: 12awr_pdb_autoflush_enabled:waarfilesystemio_options: SETALLlog_buffer: 134217728
Er is een PDB gemaakt voor de SLOB-database.
In het volgende diagram ziet u de tabelruimte PERFIO met een grootte van 600 GB (20 gegevensbestanden, elk 30 GB) die zijn gemaakt om vier SLOB-gebruikersschema's te hosten. Elk gebruikersschema was 125 GB groot.
Metrische gegevens voor prestaties
Het doel was om de IO-prestaties te rapporteren zoals ervaren door de toepassing. Daarom gebruiken alle diagrammen in dit artikel metrische gegevens die zijn gerapporteerd door de Oracle-database via de rapporten voor automatische workloadopslagplaats (AWR). De metrische gegevens die in de diagrammen worden gebruikt, zijn als volgt:
- Gemiddelde IO-aanvragen per seconde
Komt overeen met de som van de gemiddelde lees-IO-aanvragen per seconde en de gemiddelde schrijf-IO-aanvragen per seconde uit de sectie load profile - Gemiddelde IO MB/sec
Komt overeen met de som van de gemiddelde lees-IO MB per seconde en het gemiddelde schrijf-IO MB per seconde uit de sectie met het belastingprofiel - Gemiddelde leeslatentie
Komt overeen met de gemiddelde latentie van de Oracle Wait Event 'db file sequentiële leesbewerking' in microseconden - Aantal threads/schema
Komt overeen met het aantal SLOB-threads per gebruikersschema
Resultaten van prestatiemeting
In deze sectie worden de resultaten van prestatiemeting beschreven.
Linux kNFS-client versus Oracle Direct NFS
Dit scenario werd uitgevoerd op een Azure VM-Standard_D32s_v3 (Intel E5-2673 v4 @ 2,30 GHz). De workload is 75% SELECT en 25% UPDATE, voornamelijk willekeurige I/O, en met een databasebuffer van ~7,5%.
Zoals in het volgende diagram wordt weergegeven, levert de Oracle DNFS-client maximaal 2,8x meer doorvoer dan de reguliere Linux kNFS-client:
In het volgende diagram ziet u de latentiecurve voor de leesbewerkingen. In deze context is het knelpunt voor de kNFS-client de enkele NFS TCP-socketverbinding die tot stand is gebracht tussen de client en de NFS-server (het Azure NetApp Files-volume).
De DNFS-client kon meer IO-aanvragen per seconde pushen vanwege de mogelijkheid om honderden TCP-socketverbindingen te maken, waardoor er gebruik wordt gemaakt van de parallelle uitvoering. Zoals beschreven in de Configuratie van Azure NetApp Files, biedt elke extra TiB aan toegewezen capaciteit een extra bandbreedte van 128MiB/s. DNFS heeft een limiet van 1 GiB/s aan doorvoer, wat de limiet is die wordt opgelegd door de 8-TiB-capaciteitsselectie. Gezien meer capaciteit zou er meer doorvoer zijn gestuurd.
Doorvoer is slechts een van de overwegingen. Een andere overweging is latentie, die de belangrijkste invloed heeft op de gebruikerservaring. Zoals in het volgende diagram wordt weergegeven, kunnen latentiestijgingen veel sneller worden verwacht met kNFS dan met DNFS.
Histogrammen bieden uitstekend inzicht in databaselatenties. Het volgende diagram biedt een volledige weergave vanuit het perspectief van de opgenomen 'db-bestand sequentiële leesbewerking', terwijl DNFS wordt gebruikt op het hoogste gelijktijdigheidsgegevenspunt (32 threads/schema). Zoals wordt weergegeven in het volgende diagram, werden 47% van alle leesbewerkingen uitgevoerd tussen 512 microseconden en 1000 microseconden, terwijl 90% van alle leesbewerkingen werden uitgevoerd met een latentie van minder dan 2 ms.
Tot slot is het duidelijk dat DNFS een must is als het gaat om het verbeteren van de prestaties van een Oracle-database-exemplaar op NFS.
Prestatielimieten voor één volume
In deze sectie worden de prestatielimieten van één volume met willekeurige I/O en sequentiële I/O beschreven.
Willekeurige I/O
DNFS kan veel meer bandbreedte verbruiken dan wordt geleverd door een prestatiequotum van 8 TB voor Azure NetApp Files. Door de volumecapaciteit van Azure NetApp Files te verhogen naar 16 TiB, wat een onmiddellijke wijziging is, is de hoeveelheid volumebandbreedte verhoogd van 1024 MiB/s met 2X naar 2048 MiB/s.
In het volgende diagram ziet u een configuratie voor een werkbelasting van 80% selecteren en 20% bijwerken, en met een databasebufferpercentage van 8%. SLOB kon één volume naar 200.000 NFS I/O-aanvragen per seconde sturen. Aangezien elke bewerking 8 KiB-grootte heeft, kon het systeem onder test ~200.000 IO-aanvragen per seconde of 1600 MiB/s leveren.
In het volgende diagram van de leeslatentiecurve ziet u dat, naarmate de leesdoorvoer toeneemt, de latentie soepel onder de lijn van 1 ms toeneemt en de knie van de curve bereikt op ongeveer 165.000 gemiddelde LEES-IO-aanvragen per seconde bij de gemiddelde leeslatentie van ~1,3 ms. Deze waarde is een ongelooflijke latentiewaarde voor een I/O-snelheid die niet mogelijk is met vrijwel elke andere technologie in de Azure Cloud.
Sequentiële I/O
Zoals in het volgende diagram wordt weergegeven, is niet alle I/O willekeurig, gezien een RMAN-back-up of een volledige tabelscan, bijvoorbeeld omdat werkbelastingen zoveel bandbreedte vereisen als ze kunnen krijgen. Met dezelfde configuratie als eerder beschreven, maar met het volume groter dan 32 TiB, ziet u in het volgende diagram dat één Oracle DB-exemplaar 3900 MB/s doorvoer kan verhogen, zeer dicht bij het prestatiequotum van het Azure NetApp Files-volume van 32 TB (128 MB/s * 32 = 4096 MB/s).
Kortom, Met Azure NetApp Files kunt u uw Oracle-databases naar de cloud brengen. Het levert prestaties op wanneer de database deze vereist. U kunt het volumequotum op elk gewenst moment dynamisch en niet storend wijzigen.