Výkon databází Oracle na jednoduchých svazcích Azure NetApp Files

Tento článek se zabývá následujícími tématy o Oracle v cloudu. Tato témata můžou být obzvláště zajímavá pro správce databáze, cloudového architekta nebo architekta úložiště:

• Při řízení úlohy online zpracování transakcí (OLTP) (většinou náhodných vstupně-výstupních operací) nebo úlohy online analytického zpracování (OLAP) (většinou sekvenční vstupně-výstupní operace) vypadá výkon?
• Jaký je rozdíl v výkonu mezi běžným klientem systému Linux NFS (kNFS) a vlastním klientem Systému souborů NFS Oracle?
• Pokud jde o šířku pásma, stačí výkon jednoho svazku Azure NetApp Files?

Důležité

Pokud chcete správně a optimálně nasadit orace dNFS, postupujte podle zde uvedených pokynů pro opravy.

Testování prostředí a komponent

Následující diagram znázorňuje prostředí používané k testování. Pro konzistenci a jednoduchost se k nasazení všech prvků testovací postele použily playbooky Ansible.

Konfigurace virtuálního počítače

Testy pro virtuální počítač použily 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
• Disky:
  Binární soubory Oracle a operační systém byly umístěny na jednom disku úrovně Premium.

Konfigurace služby Azure NetApp Files

Testy použily následující konfiguraci služby Azure NetApp Files:

• Velikost fondu kapacity:
  Byly nakonfigurovány 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)
• Svazky:
  Jeden a dva testy svazků byly vyhodnoceny.

Generátor úloh

Testy použily úlohu vygenerovanou SLOB 2.5.4.2. SLOB (Silly Little Oracle Benchmark) je známý generátor úloh v prostoru Oracle navržený tak, aby stresoval a testoval subsystém vstupně-výstupních operací s fyzickou sadou vstupně-výstupních operací ve vyrovnávací paměti SGA.

SLOB 2.5.4.2 nepodporuje připojitelnou databázi (PDB). Změna se proto přidala do setup.sh skriptů a runit.sh přidala do ní podporu PDB.

Proměnné SLOB použité v testech jsou popsány v následujících částech.

Výběr úlohy 80 %, 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

Výběr úlohy 100 % | 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 použitá pro testy je Oracle Database edice Enterprise 19.3.0.0.

Parametry Oracle jsou následující:

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

Pro databázi SLOB byla vytvořena pdB.

Následující diagram znázorňuje prostor tabulky s názvem PERFIO s velikostí 600 GB (20 datových souborů, každý z nich 30 GB) vytvořený pro hostování čtyř uživatelských schémat SLOB. Každé uživatelské schéma bylo velikost 125 GB.

Metriky výkonu

Cílem bylo hlásit výkon vstupně-výstupních operací, které aplikace zaznamenala. Proto všechny diagramy v tomto článku používají metriky hlášené databází Oracle prostřednictvím sestav automatického úložiště úloh (AWR). Metriky použité v diagramech jsou následující:

• Průměrné vstupně-výstupní požadavky za sekundu
  Odpovídá součtu průměrných požadavků vstupně-výstupních operací čtení za sekundu a průměrnému počtu vstupně-výstupních požadavků za zápis z oddílu profilu zatížení.
• Average IO MB/s
  Odpovídá součtu průměrných vstupně-výstupních operací čtení MB/s a průměru vstupně-výstupních operací zápisu MB/s z oddílu profilu zatížení.
• Průměrná latence čtení
  Odpovídá průměrné latenci události Oracle Wait Event "db file sekvenční čtení" v mikrosekundách.
• Počet vláken/schématu
  Odpovídá počtu vláken SLOB na uživatelské schéma.

Výsledky měření výkonu

Tato část popisuje výsledky měření výkonu.

Klient kNFS s Linuxem a Oracle Direct NFS

Tento scénář byl spuštěn na virtuálním počítači Azure Standard_D32s_v3 (Intel E5-2673 v4 @ 2,30 GHz). Úloha je 75 % SELECT a 25% UPDATE, většinou náhodné vstupně-výstupní operace a s dosažením vyrovnávací paměti databáze přibližně 7,5 %.

Jak je znázorněno v následujícím diagramu, klient Oracle DNFS doručil až 2,8× vyšší propustnost než běžný klient Linuxu kNFS:

Následující diagram znázorňuje křivku latence operací čtení. V tomto kontextu je kritickým bodem klienta kNFS jediné připojení soketu TCP NFS vytvořené mezi klientem a serverem NFS (svazek Azure NetApp Files).

Klient DNFS dokázal odeslat více vstupně-výstupních požadavků za sekundu kvůli své schopnosti vytvářet stovky připojení soketů TCP, a proto využíval paralelismus. Jak je popsáno v konfiguraci Azure NetApp Files, každá další tiB přidělená kapacita umožňuje další šířku pásma 128MiB/s. DnFS se přeskočí na 1 GiB/s propustnosti, což je limit, který je stanoven výběrem kapacity 8 TiB. Vzhledem k větší kapacitě by byla vyšší propustnost řízena.

Propustnost je jen jednou z důležitých aspektů. Dalším aspektem je latence, která má primární dopad na uživatelské prostředí. Jak ukazuje následující diagram, nárůst latence se dá u kNFS očekávat mnohem rychleji než u DNFS.

Histogramy poskytují vynikající přehled o latencích databáze. Následující diagram poskytuje úplné zobrazení z pohledu zaznamenaného "sekvenčního čtení souboru db", zatímco použití DNFS v datovém bodě s nejvyšší souběžností (32 vláken/schématu). Jak je znázorněno v následujícím diagramu, 47 % všech operací čtení bylo dodrženo mezi 512 mikrosekundami a 1000 mikrosekundami, zatímco 90 % všech operací čtení bylo obsluhováno s latencí pod 2 ms.

Na závěr je zřejmé, že DNFS je nutností zlepšit výkon instance databáze Oracle v systému souborů NFS.

Omezení výkonu s jedním svazkem

Tato část popisuje limity výkonu jednoho svazku s náhodnými vstupně-výstupními operacemi a sekvenčními vstupně-výstupními operacemi.

Náhodné vstupně-výstupní operace

DNFS dokáže využívat mnohem větší šířku pásma, než poskytuje kvóta výkonu služby Azure NetApp Files o velikosti 8 TB. Zvýšením kapacity svazku Azure NetApp Files na 16 TiB, což je okamžitá změna, se objem šířky pásma svazku zvýšil z 1024 MiB/s o 2X na 2048 MiB/s.

Následující diagram znázorňuje konfiguraci pro 80% výběrovou a 20% aktualizační úlohu a s poměrem dosažení vyrovnávací paměti databáze 8 %. SLOB dokázal řídit jeden svazek na 200 000 vstupně-výstupních požadavků NFS za sekundu. Vzhledem k tomu, že každá operace je velikost 8 KiB, systém, který se testuje, dokázal dodávat přibližně 200 000 vstupně-výstupních požadavků za sekundu nebo 1600 MiB/s.

Následující diagram latence čtení ukazuje, že s nárůstem propustnosti čtení se latence hladce zvyšuje pod čárou 1 ms a při průměrné latenci čtení ~165 000 průměrných požadavků na vstupně-výstupní operace čtení za sekundu při průměrné latenci čtení ~1,3 ms dosáhne kolena křivky. Tato hodnota je neuvěřitelné latence pro rychlost vstupně-výstupních operací, která není dosažitelná s téměř 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 v přírodě náhodné, když zvažujete zálohování RMAN nebo úplné prohledávání tabulky, například jako úlohy vyžadující tolik šířky pásma, kolik získají. Použití stejné konfigurace, jak jsme popsali dříve, ale s velikostí svazku změněným na 32 TiB, následující diagram ukazuje, že jedna instance Oracle DB může zvýšit propustnost 3 900 MB/s, velmi blízko kvóty výkonu svazku Azure NetApp Files 32 TB (128 MB/s × 32 = 4096 MB/s).

Stručně řečeno, Azure NetApp Files vám pomůže převést databáze Oracle do cloudu. Poskytuje výkon, když databáze vyžaduje. Kvótu svazku můžete dynamicky a nenarušovat kdykoliv.

Další kroky

• Doporučení testů srovnávacích testů výkonu pro Azure NetApp Files
• Srovnávací testy výkonu pro Linux