Prestazioni di Oracle Database in singoli volumi con Azure NetApp Files
Questo articolo illustra gli argomenti seguenti su Oracle nel cloud. Questi argomenti possono essere di particolare interesse per un amministratore di database, un cloud architect o un architetto di archiviazione:
- Quando si guida un carico di lavoro OLTP (Online Transaction Processing) (principalmente I/O casuale) o un carico di lavoro di elaborazione analitica online (per lo più sequenziale di I/O), quali sono le prestazioni?
- Qual è la differenza nelle prestazioni tra il normale client NFS (kNFS) del kernel Linux e il client Direct NFS di Oracle?
- Per quanto riguarda la larghezza di banda, le prestazioni di un singolo volume di Azure NetApp Files sono sufficienti?
Importante
Per una distribuzione corretta e ottimale di Oracle dNFS, seguire le linee guida per l'applicazione di patch descritte qui.
Ambiente e componenti di test
Il diagramma seguente illustra l'ambiente usato per il test. Per coerenza e semplicità, sono stati usati playbook ansible per distribuire tutti gli elementi del letto di test.
Configurazione della macchina virtuale
I test hanno usato la configurazione seguente per la macchina virtuale:
- Sistema operativo:
RedHat Enterprise Linux 7.8 (wle-ora01) - Tipi di istanza:
Due modelli sono stati usati nei test: D32s_v3 e D64s_v3 - Numero di interfacce di rete:
Uno (1) posizionato nella subnet 3 - Dischi:
I file binari e il sistema operativo Oracle sono stati inseriti in un singolo disco Premium
Configurazione di Azure NetApp Files
I test hanno usato la configurazione di Azure NetApp Files seguente:
- Dimensioni del pool di capacità:
Sono state configurate varie dimensioni del pool: 4 TiB, 8 TiB, 16 TiB, 32 TiB - Livello di servizio:
Ultra (128 MiB/s di larghezza di banda per 1 TiB della capacità del volume allocata) - Volumi:
Sono stati valutati uno e due test del volume
Generatore di carichi di lavoro
I test usati hanno usato il carico di lavoro generato SLOB 2.5.4.2. SLOB (Silly Little Oracle Benchmark) è un generatore di carico di lavoro noto nello spazio Oracle progettato per stressare e testare il sottosistema di I/O con un carico di lavoro di I/O fisico memorizzato nel buffer SGA.
SLOB 2.5.4.2 non supporta il database collegabile (PDB). Di conseguenza, è stata aggiunta una modifica agli setup.sh script e runit.sh per aggiungervi il supporto PDB.
Le variabili SLOB usate nei test sono descritte nelle sezioni seguenti.
Carico di lavoro 80% SELECT, 20% UPDATE | I/O casuale : slob.conf variabili
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
Select del carico di lavoro 100% | I/O sequenziale : slob.conf variabili
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
La versione oracle usata per i test è Oracle Database edizione Enterprise 19.3.0.0.
I parametri Oracle sono i seguenti:
sga_max_size: 4096Msga_target: 4096db_writer_processes: 12awr_pdb_autoflush_enabled: truefilesystemio_options: SETALLlog_buffer: 134217728
È stato creato un PDB per il database SLOB.
Il diagramma seguente mostra lo spazio di tabella denominato PERFIO con dimensioni di 600 GB (20 file di dati, 30 GB ciascuno) creato per ospitare quattro schemi utente SLOB. Ogni schema utente ha dimensioni pari a 125 GB.
Metriche delle prestazioni
L'obiettivo era quello di segnalare le prestazioni di I/O come sperimentato dall'applicazione. Di conseguenza, tutti i diagrammi in questo articolo usano le metriche segnalate dal database Oracle tramite i report AWR (Automatic Workload Repository). Le metriche usate nei diagrammi sono le seguenti:
- Richieste di I/O medie/sec
Corrisponde alla somma delle richieste di I/O di lettura medie/sec e delle richieste di I/O di scrittura medie/sec dalla sezione del profilo di carico - Media di I/O MB/sec
Corrisponde alla somma della media di I/O MB/sec di I/O di lettura e della media di I/O di scrittura/sec dalla sezione del profilo di carico - Latenza di lettura media
Corrisponde alla latenza media dell'evento oracle wait "db file sequenziale read" in microsecondi - Numero di thread/schema
Corrisponde al numero di thread SLOB per schema utente
Risultati delle misurazioni delle prestazioni
In questa sezione vengono descritti i risultati della misurazione delle prestazioni.
Client Linux kNFS e Oracle Direct NFS
Questo scenario era in esecuzione in una macchina virtuale di Azure Standard_D32s_v3 (Intel E5-2673 v4 a 2,30 GHz). Il carico di lavoro è 75% SELECT e 25% UPDATE, principalmente I/O casuale e con un riscontro del buffer del database di circa il 7,5%.
Come illustrato nel diagramma seguente, il client Oracle DNFS ha recapitato fino a 2,8 volte più velocità effettiva rispetto al normale client Linux kNFS:
Il diagramma seguente illustra la curva di latenza per le operazioni di lettura. In questo contesto, il collo di bottiglia per il client kNFS è la singola connessione socket TCP NFS stabilita tra il client e il server NFS (volume Azure NetApp Files).
Il client DNFS è stato in grado di eseguire il push di più richieste di I/O al secondo grazie alla possibilità di creare centinaia di connessioni socket TCP, sfruttando quindi il parallelismo. Come descritto nella configurazione di Azure NetApp Files, ogni TiB aggiuntivo della capacità allocata consente un ulteriore 128MiB/s di larghezza di banda. DNFS è stato disattivato a 1 GiB/s di velocità effettiva, ovvero il limite imposto dalla selezione della capacità di 8 TiB. Data una maggiore capacità, sarebbe stata determinata una maggiore velocità effettiva.
La velocità effettiva è solo una delle considerazioni. Un'altra considerazione è la latenza, che ha l'impatto principale sull'esperienza utente. Come illustrato nel diagramma seguente, gli aumenti di latenza possono essere previsti molto più rapidamente con kNFS rispetto a DNFS.
Gli istogrammi forniscono informazioni dettagliate eccellenti sulle latenze del database. Il diagramma seguente offre una visualizzazione completa dal punto di vista della lettura sequenziale del file db registrata, usando DNFS al punto dati di concorrenza più elevato (32 thread/schema). Come illustrato nel diagramma seguente, il 47% di tutte le operazioni di lettura è stato rispettato tra 512 microsecondi e 1000 microsecondi, mentre il 90% di tutte le operazioni di lettura è stato servito a una latenza inferiore a 2 ms.
In conclusione, è chiaro che DNFS è un must-have quando si tratta di migliorare le prestazioni di un'istanza di database Oracle in NFS.
Limiti delle prestazioni di un singolo volume
Questa sezione descrive i limiti delle prestazioni di un singolo volume con operazioni di I/O casuali e I/O sequenziali.
I/O casuale
DNFS è in grado di utilizzare una larghezza di banda molto maggiore rispetto a quella fornita da una quota di prestazioni di Azure NetApp Files di 8 TB. Aumentando la capacità del volume di Azure NetApp Files a 16 TiB, che è una modifica istantanea, la quantità di larghezza di banda del volume è aumentata da 1024 MiB/s di 2X a 2048 MiB/s.
Il diagramma seguente mostra una configurazione per un carico di lavoro di selezione dell'80% e del 20% di aggiornamento e con un rapporto di riscontri nel buffer del database pari all'8%. SLOB è stato in grado di guidare un singolo volume a 200.000 richieste di I/O NFS al secondo. Considerando che ogni operazione ha dimensioni di 8 KiB, il sistema sottoposto a test è riuscito a recapitare circa 200.000 richieste di I/O al secondo o 1600 MiB/s.
Il diagramma della curva della latenza di lettura seguente mostra che, man mano che aumenta la velocità effettiva di lettura, la latenza aumenta senza problemi sotto la riga di 1 ms e raggiunge il ginocchio della curva a circa 165.000 richieste di I/O di lettura medie/sec alla latenza di lettura media di ~1,3 ms. Questo valore è un valore di latenza incredibile per una velocità di I/O non raggiungibile con quasi qualsiasi altra tecnologia nel cloud di Azure.
I/O sequenziale
Come illustrato nel diagramma seguente, non tutte le operazioni di I/O sono di natura casuale, considerando un backup RMAN o un'analisi completa della tabella, ad esempio, come carichi di lavoro che richiedono la larghezza di banda massima possibile. Usando la stessa configurazione descritta in precedenza, ma con il volume ridimensionato a 32 TiB, il diagramma seguente mostra che una singola istanza di Oracle DB può guidare verso l'alto di 3.900 MB/s di velocità effettiva, molto vicino alla quota di prestazioni del volume di Azure NetApp Files di 32 TB (128 MB/s * 32 = 4096 MB/s).
In sintesi, Azure NetApp Files consente di portare i database Oracle nel cloud. Offre prestazioni ottimali quando il database lo richiede. È possibile ridimensionare in qualsiasi momento la quota del volume in modo dinamico e senza interruzioni.