Výkon databází Oracle na jednoduchých svazcích Azure NetApp Files
Tento článek popisuje následující témata týkající se Oracle v cloudu. Tato témata můžou být obzvláště důležitá pro správce databáze, architekta cloudu nebo architekta úložiště:
- Čím je úloha online zpracování transakcí (OLTP) (většinou náhodných vstupně-výstupních operací) nebo úlohy OLAP (Online Analytical Processing) (většinou sekvenční vstupně-výstupní operace), co vypadá s výkonem?
- Jaký je rozdíl mezi výkonem normálního klienta systému Linux NFS (kNFS) a klienta pro systém souborů NFS s přímým přístupem k systému souborů Oracle?
- Pokud jde o šířku pásma, je k dispozici výkon jednoho Azure NetApp Filesho svazku?
Testovací prostředí a součásti
Následující diagram znázorňuje prostředí používané pro testování. Pro zajištění konzistence a jednoduchosti byly použity Ansible playbooky pro nasazení všech prvků zkušebního DNA.

Konfigurace virtuálního počítače
Testy použily pro virtuální počítač následující nastavení:
- Operační systém:
RedHat Enterprise Linux 7,8 (wle-ora01) - Typy instancí:
Při testování byly použity dva modely – D32s_v3 a D64s_v3 - Počet síťových rozhraní:
Jedna (1) umístěná v podsíti 3 - Disků
Binární soubory a operační systémy Oracle byly umístěny na jeden disk Premium
Konfigurace Azure NetApp Files
Testy používaly následující konfiguraci Azure NetApp Files:
- Velikost fondu kapacity:
Byly nakonfigurované různé velikosti fondu: 4 TiB, 8 TiB, 16 TiB, 32 TiB - Úroveň služby:
Ultra (128 MiB/s šířky pásma na 1 TiB přidělené kapacity svazku) - Svazků
Jeden a dva testy svazků byly vyhodnoceny
Generátor úloh
Testy použily vygenerované úlohy SLOB 2.5.4.2. SLOB (Silly Little Oracle test) je známý generátor úloh v prostoru Oracle, který je určený k zatížení a testování subsystému v/v s využitím fyzického vstupně-výstupního zatížení s SGA vyrovnávací pamětí.
SLOB 2.5.4.2 nepodporuje připojení k databázi (PDB). V takovém případě se do skriptů a přidala změna, setup.sh runit.sh aby se do ní přidala podpora PDB.
Proměnné SLOB použité v testech jsou popsány v následujících částech.
Zatížení 80% SELECT, 20% aktualizace | Náhodné vstupně-výstupní operace – slob.conf proměnné
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
Pracovní vytížení 100% vyberte | Sekvenční vstupně-výstupní operace – slob.conf proměnné
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
databáze
Verze Oracle, která se používá pro testy, je Oracle Database Enterprise Edition 19.3.0.0.
Parametry Oracle jsou následující:
sga_max_size: 4096Msga_target: 4096db_writer_processes: 12awr_pdb_autoflush_enabled: truefilesystemio_options: SETALLlog_buffer: 134217728
Pro databázi SLOB byl vytvořen soubor PDB.
Následující diagram znázorňuje tabulkový prostor s názvem PERFIO s 600 GB (20 datových souborů, 30 GB každého), který se vytvořil pro hostování čtyř uživatelských schémat SLOB. Každé schéma uživatele má velikost 125 GB.

Metriky výkonu
Cílem bylo ohlásit vstupně-výstupní výkon, který aplikace má. Proto všechny diagramy v tomto článku používají metriky hlášené databází Oracle prostřednictvím svých sestav úložiště automatických úloh (AWR). Metriky používané v diagramech jsou následující:
- Průměrný počet vstupně-výstupních požadavků za sekundu
Odpovídá součtu průměrných požadavků na vstupně-výstupní operace čtení/sec a průměrného počtu požadavků na vstupně-výstupní operace zápisu za sekundu z oddílu zátěžového profilu. - Průměr v/v MB/s
Odpovídá součtu průměrných vstupně-výstupních operací čtení MB/s a průměrného zápisu v/v za sekundu v části profil zatížení. - Průměrná latence čtení
Odpovídá průměrné latenci události čekání Oracle "sekvenční čtení souboru" v mikrosekundách - Počet vláken/schémat
Odpovídá počtu vláken SLOB na schéma uživatele.
Výsledky měření výkonu
Tato část popisuje výsledky měření výkonu.
Klient pro Linux kNFS vs. Oracle Direct NFS
Tento scénář je spuštěný na virtuálním počítači Azure Standard_D32s_v3 (Intel E5-2673 V4 @ 2,30 GHz). Zatížení je 75% SELECT a 25% aktualizace, většinou náhodných vstupně-výstupních operací, a s dosažením vyrovnávací paměti databáze ~ 7,5%.
Jak je znázorněno v následujícím diagramu, klient Oracle DNFS se doručí až na 2,8 × větší propustnost než běžný klient pro Linux kNFS:

Následující diagram znázorňuje křivku latence pro operace čtení. V tomto kontextu je kritickým bodem pro klienta kNFS jedno připojení soketu TCP systému souborů NFS navázané mezi klientem a serverem NFS (Azure NetApp Files svazek).

Klient DNFS mohl odeslat více vstupně-výstupních požadavků za sekundu, protože umožňuje vytvořit stovky připojení soketu TCP, a díky tomu využít paralelismus. Jak je popsáno v tématu konfigurace Azure NetApp Files, jednotlivé další TIB kapacity umožňují další 128MiB/s šířky pásma. DNFS topped z 1 GiB/s propustnost, což je limit, který je nastaven na 8-TiB. S ohledem na větší kapacitu by byla zařízena větší propustnost.
Propustnost je pouze jedním z důležitých informací. Dalším aspektem je latence, která má primární dopad na činnost koncového uživatele. Jak ukazuje následující diagram, zvýšení latence je možné očekávat mnohem rychleji s kNFS než s DNFS.

Histogramy poskytují vynikající přehled o latencích databáze. Následující diagram nabízí kompletní pohled z perspektivy zaznamenaného sekvenčního čtení souboru databáze při použití DNFS v nejvyšší datovém bodě souběžnosti (32 vláken/schémat). Jak je znázorněno v následujícím diagramu, 47% všech operací čtení bylo dodrženo mezi 512 mikrosekundami a 1000 mikrosekund, zatímco 90% všech operací čtení byla obsluhována latencí pod 2 MS.

V závěru je jasné, že DNFS se musí nacházet v případě, že se zvyšuje výkon instance databáze Oracle v systému souborů NFS.
Omezení výkonu s jedním svazkem
Tato část popisuje omezení výkonu jednoho svazku s náhodnými vstupně-výstupními operacemi a sekvenční vstupně-výstupní operace.
Náhodné vstupně-výstupní operace
DNFS je schopný spotřebovat mnohem větší šířku pásma, než je k dispozici 8 TB Azure NetApp Files kvóty výkonu. Zvýšením kapacity Azure NetApp Files svazku na 16 TiB, což je okamžitá změna, objem šířky pásma se zvýšil z 1024 MiB/s o dvojnásobek na 2048 MiB/s.
Následující diagram znázorňuje konfiguraci pro úlohu 80% Select a 20% aktualizace a s poměrem přístupů do vyrovnávací paměti databáze 8%. SLOB byl schopný zařídit jeden svazek na vstupně-výstupní požadavky 200 000 NFS za sekundu. Vzhledem k tomu, že každá operace má 8 – KiB velikost, testovaný systém byl schopný doručovat ~ 200 000 IO požadavky/s nebo 1600 MiB/s.

Následující diagram zatáčky latence čtení ukazuje, že se při zvýšení propustnosti čtení latence zvyšuje plynule pod 1-MS čárou 165 000 a při průměrné latenci čtení v/v Průměrná doba čtení v ~ 1,3 MS. Tato hodnota je nestavová latence pro rychlost vstupu a výstupu nedosažitelná s skoro jakoukoli jinou technologií v cloudu Azure.

Sekvenční vstupně-výstupní operace
Jak je znázorněno v následujícím diagramu, ne všechny vstupně-výstupní operace jsou náhodné a berou v úvahách RMAN zálohování nebo úplnou kontrolu tabulek, například jako úlohy, které vyžadují velkou šířku pásma, jak můžou získat. Pomocí stejné konfigurace, jak je popsáno dříve, ale se svazkem se změnila velikost 32 TiB, následující diagram ukazuje, že jediná instance Oracle DB může prosazovat vzhůru až 3 900 MB/s propustností, velmi blízko kvóty výkonu Azure NetApp Files svazku 32 TB (128 MB/s × 32 = 4096 MB/s).

V souhrnu vám Azure NetApp Files pomůže přebírat databáze Oracle do cloudu. Poskytuje výkon, pokud to databáze vyžaduje. Kvótu svazku můžete kdykoli dynamicky a bez přerušení měnit.