Ottimizzazione delle prestazioni di Oracle in Bare Metal Solution
Obiettivo
Questo documento fornisce linee guida su come affrontare i problemi relativi alle prestazioni utilizzando la soluzione Oracle su Bare Metal.
Passaggio 1: raccogli i dati diagnostici
Comprendi il problema nel modo più dettagliato possibile. Raccogli il maggior numero possibile di informazioni, tra cui:
- Informazioni sull'ambiente del database: ID/IP della macchina, posizione del data center, dettagli sull'ambiente Oracle e così via.
- Descrizione del problema, inclusa la cronologia.
- Entità dell'impatto: ad esempio, il problema riguarda solo una singola sessione o un singolo server, un insieme di sessioni e server correlati o tutti gli utenti del database?
- Descrivi l'indagine eseguita finora. Esistono soluzioni alternative?
- Il problema può essere riprodotto a piacimento? Se sì, in che modo?
- Esistono dati di riferimento validi con cui fare il confronto?
- Di recente sono state apportate modifiche alle configurazioni a livello di database, host, rete, archiviazione o applicazione, incluse eventuali modifiche al carico di lavoro?
- Raccogli tutti i log e le tracce pertinenti, inclusi ASH, AWR, log di avviso, file di traccia e log di TFA/OS Watcher.
# TFA command to generate a bundled package containing files like
# the AWR report, ADDM report, ASH report, OSWatcher and ORAchk performance
# related checks.
tfactl diagcollect -srdc dbperf
Passaggio 2: analizza e crea consigli
Non esitare a saltare le sezioni in base ai dati raccolti sopra.
2.1 Integrità dell'host del database
Eseguire un rapido controllo di integrità sull'host del database è un buon inizio. Dovresti essere in grado di utilizzare i file TFA/OSWatcher per il periodo in cui si è verificato il problema. In sostanza, stai cercando segni di saturazione delle risorse, utilizzo
e/o errori. Puoi anche utilizzare BMS Infrascope
per comprendere il tuo ambiente a un livello generale utilizzando machine-id,
lun-id e così via.
2.2.1 Log di sistema
/var/log/messagesodmesgpossono essere utilizzati per identificare potenziali problemi a livello di archiviazione e rete, come rilevati dal sistema.# System messages cat /var/log/messages Or dmesg -T
CPU 2.2.2
"uptime"/"top" può essere utilizzato per visualizzare i carichi medi del sistema negli ultimi 1/5/15 minuti. Tieni conto del numero di core della CPU quando esamini questi numeri. Su Linux, questi numeri includono il numero di proc su cpu/in attesa di cpu, nonché quelli in sospensione non interruptible(in genere i/o sul disco). Di seguito sono riportati alcuni comandi utili.
# To find load average "w" Or "uptime" Or "top" [root@svr001 ~]# uptime 21:32:09 up 12 days, 1:04, 3 users, load average: 0.31, 0.44, 0.64 # To find CPU Usage over time "sar -u 5" [root@svr001 ~]# sar -u 5 Linux 4.14.35-2025.401.4.el7uek.x86_64 (svr001) 12/16/2020 _x86_64_ (16 CPU) 09:52:20 PM CPU %user %nice %system %iowait %steal %idle 09:52:25 PM all 0.63 0.00 0.73 0.11 0.00 98.52 09:52:30 PM all 1.10 0.00 0.82 0.15 0.00 97.93 # To list the no. of processes in Runnable (R) and in Uninterruptible sleep (D) states "ps -eo s,user,cmd | grep ^[RD] | sort | uniq -c | sort -nbr | head -20"
2.2.3 Memoria
Utilizza "free" per trovare la memoria libera "disponibile". Un sistema in buone condizioni dovrebbe avere spazio sufficiente.
# Find system memory usage "free -m" [root@svr001 ~]# free -m total used free shared buff/cache available Mem: 385423 16603 188217 153744 180602 211778 Swap: 16383 0 16383"vmstat" può essere utilizzato per visualizzare le statistiche dello scambio (si,so). In un sistema in buono stato, dovresti vedere zero. Fornisce anche altre colonne interessanti per procs/memory/cpu ecc. che possono essere di interesse a seconda del problema.
# Virtual Mem stats 5 snapshots 5 secs apart "vmstat 5 5" [root@svr001 ~]# vmstat 5 5 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 192717472 497132 184439376 0 0 82 35 2 0 1 1 98 0 0 1 0 0 192717520 497132 184439616 0 0 3225 719 15118 29594 1 1 98 0 0Valuta la possibilità di attivare le pagine di grandi dimensioni se non sono già attive per sfruttare la dimensione maggiore delle pagine e il blocco SGA nella memoria di sistema.
- Verifica l'utilizzo di hugepage nella sezione init.ora del report AWR (use_large_pages impostato su only) o nella sezione di avvio dell'istanza in alert.log.
- Anche il mancato utilizzo di hugepages può causare lo scambio di sistema e un maggiore utilizzo della memoria per connessione al database.
2.2.4 Spazio di archiviazione
"iostat" può essere utilizzato per visualizzare le statistiche dei dispositivi di blocco come await, avgqu-sz, %util che potrebbero indicare saturazione dello spazio di archiviazione, prestazioni inferiori alla media e così via.
# IO Stats with extended per-disk statistics "iostat -x 5 5" Or "sar -dp" # For devices with 90% utilization and above "sar -dp | awk '/%util/ || ($11 > 90)'" [root@svr001 ~]# iostat -x 5 5 Linux 4.14.35-2025.401.4.el7uek.x86_64 (svr001) 12/16/2020 _x86_64_ (16 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 1.05 0.01 0.77 0.09 0.00 98.08 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sde 0.00 0.00 0.17 0.83 7.10 20.12 54.46 0.04 41.10 18.91 45.57 1.12 0.11 sdf 0.00 0.00 0.00 0.00 0.00 0.00 43.50 0.00 1.03 1.03 0.00 0.75 0.00 sdc 0.00 0.00 0.00 0.00 0.00 0.00 40.15 0.00 0.40 0.40 0.00 0.22 0.00 sda 0.00 0.00 1.16 20.80 7.76 177.15 16.84 0.02 0.82 0.73 0.83 0.14 0.31 sdd 0.00 0.00 43.24 8.03 639.16 97.67 28.75 0.01 0.20 0.18 0.31 0.18 0.92Se noti una saturazione con l'I/O, alcuni buoni punti di partenza sono:
- Il QOS per il numero di IOPS (blocchi da 8 KB) per i volumi SSD è 6000 per terabyte. Google non fornisce il QoS per l'HDD. Imposta le aspettative corrette utilizzando questi numeri.
- Se non vedi la qualità del servizio prevista sopra, il passaggio successivo potrebbe essere assicurarti di aver rispettato le best practice relative alla configurazione dello spazio di archiviazione.
Ogni server BMS ha 4 NIC da 25 Gbps ciascuna, accoppiate a due NIC da 50 Gb utilizzando la aggregazione dinamica dei link 802.3ad (attivo-attivo).
# Interface Transfer Speed # bond0 is the primary interface in this case. [root@svr001 ~]# ethtool bond0 | grep -i speed Speed: 50000Mb/sCiò significa che ( 50000 Mb/s = 6250 MB/s = 6.400.000 KB/s) è il punto di saturazione per l'interfaccia di rete principale.
# Interface stats "sar -n DEV | head -3 && sar -n DEV | grep bond0" [root@svr001 ~]# sar -n DEV | head -3 && sar -n DEV | grep bond0 12:00:01 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s 12:10:01 AM bond0.118 87.30 49.94 69.45 24.93 0.00 0.00 0.00 12:10:01 AM bond0 89.31 52.26 71.58 25.59 0.00 0.00 2.00 12:20:01 AM bond0.118 21.91 13.21 18.92 8.02 0.00 0.00 0.00 12:20:01 AM bond0 23.94 15.55 19.65 8.39 0.00 0.00 2.00
Utilizza strumenti comuni come ping, traceroute, tnsping e così via per cercare possibili problemi di rete come perdita di pacchetti/latenza tra le macchine utente/app e il server db. Per ulteriori informazioni, consulta questo tutorial.
# Quick check for 9000 mtu. # If not configured correctly, we will see "Message too long" errors ping -c 5 -s 8972 -M do <IP>Esaminare le statistiche di interconnessione nel report AWR e confrontarle con una buona base di riferimento, nonché utilizzare il comando "netstat -s" (contatori delle statistiche IP) per rilevare errori di frammentazione/riassemblaggio, problemi di overflow del buffer e così via, potrebbe fornirci indizi sull'integrità della rete privata.
# Interface errors: [root@svr001 ~]netstat -s | egrep "IP|Ip|ip:|TCP|Tcp|tcp:|UDP|Udp|udp:|ICMP|Icmp|icmp:|IGMP|igmp:|icmpv6:|ipv6:|drop|Drop|dropped|Dropped|error|Error|discard|Discard|timeout|Timeout|fail|Fail|Receive|receive" Ip: 168848352 total packets received 0 incoming packets discarded 701 outgoing packets dropped 3265322 fragments received ok
2.3 Integrità del database
Ora che conosci l'integrità complessiva del sistema e hai fatto osservazioni utili, puoi esaminare più da vicino il livello del database. A seconda della natura del problema, assicurati di raccogliere tutti i report pertinenti (awr, ash e così via) e i file di log (tfa, log di avviso, file di traccia e così via) che potrebbero essere utili per diagnosticare il problema.
Ecco alcune delle aree chiave da esaminare nel report AWR:
Parte superiore del report
- Il riepilogo dell'ambiente fornisce informazioni sul software Oracle, sull'host come core, memoria, tempo trascorso rispetto al tempo del database e così via.
- Il profilo di caricamento ci fornisce informazioni su tempo del database rispetto alla CPU del database, statistiche di analisi, statistiche I/O e così via.
- Tempo DB = CPU DB + Tempo in attesa + in attesa di CPU (coda di esecuzione)
- CPU DB = tempo di esecuzione in CPU (coda di esecuzione non inclusa)
- Sessione attiva media = tempo del database / tempo trascorso
- cpu db al secondo / (num_cpus * secondi trascorsi) fornisce informazioni sulla saturazione della CPU da parte del database
Init.ora
- Cerca eventuali parametri (underscore, relativi a Data Guard e così via) che potrebbero essere un attivatore.
Eventi principali con timer in primo piano
- Esamina la distribuzione del tempo del database per identificare il maggiore potenziale di miglioramento.
- Cerca le attese principali visualizzate nella sezione e le relative caratteristiche di rendimento, come DBTime%, classe di attesa, tempo medio e così via.
- A seconda degli eventi rilevati in questa sezione, potremmo approfondire altre sezioni del report AWR.
Statistiche del modello temporale
- Alcune delle statistiche importanti da esaminare in questa sezione sono relative all'analisi, al tempo CPU in background, al tempo di esecuzione di SQL e alla CPU del database.
- In genere, sono preferibili tempi di elaborazione SQL elevati e tempi di analisi bassi. Il tempo di esecuzione di SQL molto più elevato rispetto alla CPU del database può indicare tempi di attesa di I/O elevati.
Eventi di attesa Oracle comuni relativi a problemi di infrastruttura
log file sync:
- La sincronizzazione dei file di log può essere causata da problemi di infrastruttura di base o
a causa del design dell'applicazione. Di seguito sono riportate alcune linee guida che possono essere utilizzate per determinare se l'infrastruttura in degrado contribuisce a questo evento di attesa.
- La sincronizzazione dei file di log può essere causata sia da scarse prestazioni dello spazio di archiviazione locale sia da quello remoto e/o dalla rete se è coinvolto DataGuard.
- Le prestazioni di scrittura parallela dei file di log sono un buon indicatore della presenza di latenze nell'archiviazione locale che influiscono direttamente sulle prestazioni della sincronizzazione dei file di log. Puoi esaminare gli istogrammi degli eventi di attesa e confrontarli con buone basi di riferimento per rilevare eventuali variazioni recenti. Una scrittura su disco ottimale tipica è più vicina a 10 ms.
- La configurazione di DataGuard con massima disponibilità/protezione potrebbe essere un altro fattore che contribuisce al problema. Potresti esaminare le attese relative alla protezione dei dati e le relative istergrammi potrebbero indicare latenze della rete e/o problemi di I/O sul sito di standby.
- Un'altra causa è un lgwr occupato a causa di commit eccessivi o fame di CPU. La statistica "tempo CPU in background" deve essere controllata per verificare che non rappresenti una parte significativa del tempo del database.
- La sincronizzazione dei file di log può essere causata da problemi di infrastruttura di base o
a causa del design dell'applicazione. Di seguito sono riportate alcune linee guida che possono essere utilizzate per determinare se l'infrastruttura in degrado contribuisce a questo evento di attesa.
Tempo di attesa relativo a Cloud Storage:
- Oltre a consigliare di ottimizzare le applicazioni chattare o i problemi di hotspot, devi verificare ed eliminare la possibilità di colli di bottiglia del rendimento delle interconnessioni.
- BLOCCHI CACHE GLOBALI PERDUTI/CORROTTI deve essere il più vicino possibile a zero.
- LOST: blocca le perdite durante i trasferimenti. Potrebbe indicare problemi di rete
- CORRUPT: i valori elevati indicano un problema di IPC, di rete o hardware.