Oracle-Leistungsoptimierung in Bare-Metal-Lösung
Ziel
In diesem Dokument wird erläutert, wie Sie mit Oracle auf Bare-Metal-Lösung leistungsbezogene Probleme beheben.
Schritt 1: Diagnosedaten erfassen
Versuchen Sie, das Problem so detailliert wie möglich nachzuvollziehen. Erheben Sie so viele Informationen wie möglich, darunter folgende:
- Informationen zur Datenbankumgebung: Maschinen-ID/-IP, Standort des Rechenzentrums, Details der Oracle-Umgebung usw.
- Problembeschreibung einschließlich Zeitachse.
- Reichweite der Auswirkungen: Betrifft das Problem beispielsweise nur eine einzelne Sitzung bzw. einen einzelnen Server oder eine Reihe verbundener Sitzungen bzw. Server oder alle Nutzer der Datenbank?
- Beschreiben Sie die bisher ausgeführte Untersuchung des Problems. Gibt es Behelfslösungen?
- Kann das Problem nach Belieben reproduziert werden? Falls ja, wie?
- Gibt es gute Referenzdaten für einen Vergleich?
- Wurden in letzter Zeit Konfigurationen auf Datenbank-, Host-, Netzwerk-, Speicher- oder Anwendungsebene geändert, einschließlich Änderungen an der Arbeitslast?
- Erfassen Sie alle relevanten Logs und Traces, einschließlich ASH-, AWR-, Benachrichtigungs-, Trace- und TFA-/OS-Watcher-Logs.
# 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
Schritt 2: Empfehlungen analysieren und erstellen
Je nach den Daten, die Sie oben erfasst haben, können Sie hier einzelne Abschnitte überspringen.
2.1 Status des Datenbankhosts
Es wird empfohlen, zuerst kurz eine Systemdiagnose für den Datenbankhost auszuführen. Dazu müssen TFA/OSWatcher-Dateien für den Problemzeitraum verwendet werden können. Im Wesentlichen wird dabei nach Anzeichen für Ressourcenauslastung, -nutzung und/oder -fehler gesucht. Mit BMS Infrascope können Sie auch allgemein den Status Ihrer Umgebung anhand der Maschinen-ID, Lun-ID usw. ermitteln.
2.2.1 Systemlogs
Mit
/var/log/messagesoderdmesgkönnen potenzielle Probleme auf Speicher- und Netzwerkebene wie vom System angezeigt ermittelt werden.# System messages cat /var/log/messages Or dmesg -T
2.2.2 CPU
Mit "uptime"/"top" kann die durchschnittliche Systemauslastung in den letzten 1/5/15 Minuten ermittelt werden. Bei der Interpretation dieser Zahlen muss die Anzahl der CPU-Kerne berücksichtigt werden. Unter Linux umfassen diese Zahlen die Anzahl der Prozesse in Bezug auf CPU/Warten auf die CPU sowie diejenigen im unterbrechungsfreien Ruhemodus (in der Regel Laufwerk-E/A). Im Folgenden sind einige hilfreiche Befehle dazu aufgeführt.
# 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 Arbeitsspeicher
Verwenden Sie "free", um den verfügbaren freien Arbeitsspeicher zu ermitteln. Für ein fehlerfreies System muss ausreichend Arbeitsspeicher zur Verfügung stehen.
# 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 16383Mit "vmstat“ können Swap-Statistiken (si, so) aufgerufen werden. Für ein fehlerfreies System sollte null angezeigt werden. Hier sind außerdem weitere relevante Spalten für "procs/memory/cpu" usw. enthalten, die je nach Problem eine Rolle spielen sein können.
# 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 0Sie sollten HugePages aktivieren, wenn diese noch nicht aktiviert sind, um eine höhere Seitengröße und die sga-Sperre im Systemarbeitsspeicher zu nutzen.
- Prüfen Sie die Nutzung von Hugepages im Abschnitt "init.ora" des awr-Berichts (es muss nur "use_large_pages" festgelegt sein) oder im Startabschnitt der Instanz in "alert.log".
- Wenn keine Hugepages verwendet werden, kann dies auch zu einem System-Swapping und zu einer höheren Arbeitsspeichernutzung pro Verbindung mit der Datenbank führen.
2.2.4 Speicher
Mit "iostat" können Blockgerätestatistiken wie "await", "averagequa-sz" und "%util" aufgerufen werden, die eventuell auf die Speicherauslastung, eine unterdurchschnittliche Leistung usw. hinweisen.
# 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.92Im Folgenden sind einige hilfreiche Ausgangspunkte für die Anzeige der E/A-Auslastung aufgeführt:
- Die QOS für die Anzahl der IOPS (8.000 Blöcke) für SSD-Volumes beträgt 6.000 pro Terabyte. Google bietet keine QOS für HDDs. Legen Sie die gewünschten QOS-Einstellungen anhand dieser Zahlen fest.
- Wenn die gewünschte QOS nicht angezeigt wird, können Sie als Nächstes prüfen, ob Sie den Best Practices für die Speicherkonfiguration gefolgt sind.
Jeder BMS-Server hat vier NICs mit jeweils 25 Gbit/s, die über die dynamische 802.3ad-Link-Aggregation (Aktiv-Aktiv) mit zwei 50-GB-NICs verbunden sind.
# Interface Transfer Speed # bond0 is the primary interface in this case. [root@svr001 ~]# ethtool bond0 | grep -i speed Speed: 50000Mb/sDas bedeutet, dass (50.000 MB/s = 6.250 MB/s = 6.400.000 KB/s) der Auslastungspunkt für die primäre Netzwerkschnittstelle ist.
# 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
Verwenden Sie gängige Tools wie Ping, Traceroute, Tnsping usw., um mögliche Netzwerkproblemen wie Paketverlust/-latenz zwischen Nutzer-/Anwendungscomputern und dem DB-Server zu ermitteln. Weitere Informationen finden Sie in dieser Anleitung.
# Quick check for 9000 mtu. # If not configured correctly, we will see "Message too long" errors ping -c 5 -s 8972 -M do <IP>Die Prüfung der Interconnect-Statistiken im awr-Bericht und der Vergleich mit guten Referenzdaten sowie die Verwendung des Befehls "netstat -s" (IP-Statistik-Zähler), um Fehler bei der Fragmentierung/Zusammensetzung, Pufferüberlaufprobleme usw. zu ermitteln, kann Hinweise auf den Status des privaten Netzwerks geben.
# 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 Datenbankstatus
Nachdem Sie nun den Gesamtsystemstatus ermittelt und hilfreiche Informationen dazu erhalten haben, können Sie sich die Datenbankebene genauer ansehen. Erfassen Sie je nach Art des Problems alle relevanten Berichte (awr, ash usw.) und Logdateien (tfa, Benachrichtigungslogs, Trace-Dateien usw.), die bei der Diagnose des Problems helfen können.
Im Folgenden sind einige der wichtigsten Bereiche im awr-Bericht aufgeführt:
Oberer Teil des Berichts
- Die Zusammenfassung über die Umgebung informiert über Oracle-s/w-Informationen, Hostinformationen wie Kerne, Arbeitsspeicher, verstrichene Zeit im Vergleich zur DB-Zeit usw.
- Das Ladeprofil enthält Informationen über die DB-Zeit im Vergleich zu DB-CPU, Parsing-Statistiken, E/A-Statistiken usw.
- DB-Zeit = DB-CPU + Wartezeit + Warten auf die CPU (Ausführungswarteschlange)
- DB-CPU = Zeit für die Ausführung in CPU (ohne Ausführungswarteschlange)
- Durchschnittliche aktive Sitzung = DB-Zeit/verstrichene Zeit
- DB-CPU pro Sekunde/(Anzahl CPUs * verstrichene Sekunden) liefert Informationen zur CPU-Auslastung durch die Datenbank
init.ora
- Ermitteln Sie hier Parameter (Unterstrich, Data Guard-bezogen usw.), die ein Auslöser sein können.
Häufigste zeitgesteuerte Ereignisse im Vordergrund
- Prüfen Sie die Verteilung der DB-Zeit, um das größte Verbesserungspotenzial zu ermitteln.
- Ermitteln Sie die größten Wartezeiten im Abschnitt und deren Leistungsparameter wie DBTime%, wait-Klasse und durchschnittliche Zeit usw.
- Je nachdem, welche Ereignisse in diesem Abschnitt enthalten sind, kann in weitere Abschnitte des awr-Berichts aufgeschlüsselt werden.
Zeitmodell-Statistiken
- Wichtige Statistiken, die in diesem Abschnitt geprüft werden sollten, sind parsingbezogene Hintergrund-CPU-Zeit, verstrichene SQL-Ausführungszeit, DB-CPU.
- Im Allgemeinen sind eine hohe SQL-Verarbeitungszeit und niedrige Parsing-Zeiten von Vorteil. Eine höhere verstrichene Zeit für die SQL-Ausführung als die DB-CPU weist eventuell auf hohe E/A-Wartezeiten hin.
Häufige Oracle-Warteereignisse im Zusammenhang mit Infrastrukturproblemen
Logdateisynchronisierung:
- Die Synchronisierung von Logdateien kann sowohl durch zugrunde liegende Infrastrukturprobleme als auch aufgrund des Anwendungsdesigns ausgelöst werden. Anhand der folgenden Richtlinien können Sie feststellen, ob eine beeinträchtigte Infrastruktur zu diesem Warteereignis führt.
- Die Synchronisierung von Logdateien kann sowohl durch schlechte Leistungswerte des lokalen Speichers als auch durch die Speicherung per Fernzugriff und/oder durch das Netzwerk ausgelöst werden, wenn Data Guard beteiligt ist.
- Die parallele Schreibleistung der Log-Datei ist ein guter Indikator dafür, ob die Latenz im lokalen Speicher die Leistung der Synchronisierung von Logdateien direkt beeinflusst. Sie können durch Prüfung der Histogramme von Warteereignissen und Vergleich mit guten Referenzwerten aktuelle Abweichungen ermitteln. Ein typischer optimaler Schreibvorgang auf das Laufwerk würde ca. 10 ms dauern.
- Eine Einrichtung für eine maximale Verfügbarkeit bzw. für einen Data Guard-Schutz kann hier ebenfalls eine Rolle spielen. Prüfen Sie beispielsweise die Wartezeiten für Data Guard. Die Histogramme weisen eventuell auf Netzwerklatenzen und/oder E/A-Probleme am Standby-Standort hin.
- Eine weitere Ursache kann ein ausgelasteter lgwr-Wert aufgrund übermäßiger Commits oder zu wenig CPU sein. Die Statistik für "background cpu time" sollte ebenfalls geprüft werden. Sie darf keinen großen Anteil an der DB-Zeit haben.
- Die Synchronisierung von Logdateien kann sowohl durch zugrunde liegende Infrastrukturprobleme als auch aufgrund des Anwendungsdesigns ausgelöst werden. Anhand der folgenden Richtlinien können Sie feststellen, ob eine beeinträchtigte Infrastruktur zu diesem Warteereignis führt.
Cloud Storage-bezogene Wartezeiten:
- Neben dem Optimieren von Chatty-Anwendungen oder dem Beheben von Problemen des Heißlaufens sollten Sie mögliche Engpässe bei der Interconnect-Leistung prüfen und gegebenenfalls beseitigen.
- GLOBAL CACHE BLOCKS LOST/CORRUPT sollte so nahe wie möglich an null liegen.
- LOST: Blockverluste bei Übertragungen. Kann auf Netzwerkprobleme hinweisen
- CORRUPT: Hohe Werte weisen auf ein IPC-, Netzwerk- oder Hardwareproblem hin.