Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Wichtige Konzepte für die Optimierung der Datenbankleistung

DevOpsGuru für RDS geht davon aus, dass Sie mit einigen wichtigen Leistungskonzepten vertraut sind. Weitere Informationen zu diesen Konzepten finden Sie unter Übersicht über Performance Insights im Amazon-Aurora-Benutzerhandbuch oder Übersicht über Performance Insights im Amazon-RDS-Benutzerhandbuch.

Metriken

Eine Metrik stellt einen chronologisch sortierten Satz von Datenpunkten dar. Sie können sich eine Metrik als eine zu überwachende Variable und die Datenpunkte als die Werte dieser Variablen im Laufe der Zeit vorstellen. Amazon RDS stellt Metriken in Echtzeit für die Datenbank und für das Betriebssystem (OS) bereit, auf dem Ihre DB-Instance ausgeführt wird. Sie können alle Systemmetriken und Prozessinformationen für Ihre Amazon-RDS-DB-Instances in der Amazon-RDS-Konsole anzeigen. DevOpsGuru für RDS überwacht und bietet Einblicke in einige dieser Metriken. Weitere Informationen finden Sie unter Überwachen von Metriken in einem Amazon-Aurora-Cluster oder Überwachen von Metriken in einer Amazon Relational Database Service-Instance.

Problemerkennung

DevOpsGuru für RDS verwendet Datenbank- und Betriebssystemmetriken (OS), um kritische Probleme mit der Datenbankleistung zu erkennen, unabhängig davon, ob diese Probleme drosseln oder anstehen. Es gibt zwei primäre Möglichkeiten, wie DevOpsGuru für die RDS-Problemerkennung funktioniert:

Erkennen von Problemen mit Schwellenwerten

Schwellenwerte sind die Begrenzungswerte, anhand derer die überwachten Metriken ausgewertet werden. Sie können sich einen Schwellenwert als horizontale Linie in einem Metrikdiagramm vorstellen, das das normale Verhalten von potenziell problematischem Verhalten trennt. DevOpsGuru für RDS überwacht bestimmte Metriken und erstellt Schwellenwerte, indem analysiert wird, welche Stufen für eine bestimmte Ressource als potenziell problematisch angesehen werden. DevOpsGuru für RDS erstellt dann in der DevOpsGuru-Konsole Einblicke, wenn neue Metrikwerte einen bestimmten Schwellenwert über einen bestimmten Zeitraum hinweg konsistent überschreiten. Die Erkenntnisse enthalten Empfehlungen, um zukünftige Auswirkungen auf die Datenbankleistung zu vermeiden.

Beispielsweise DevOpskannGuru für RDS die Anzahl der temporären Tabellen überwachen, die die Festplatte über einen Zeitraum von 15 Minuten verwenden, und einen Einblick erstellen, wenn die Rate temporärer Tabellen, die die Festplatte pro Sekunde verwenden, ungewöhnlich hoch ist. Eine erhöhte Nutzung temporärer Tabellen auf der Festplatte kann sich auf die Datenbankleistung auswirken. Wenn Sie diese Situation an den Tag legen, bevor sie kritisch wird, hilft Ihnen DevOpsGuru für RDS dabei, Korrekturmaßnahmen zu ergreifen, um Probleme zu vermeiden.

Erkennen von Problemen mit Anomalien

Schwellenwerte bieten zwar eine einfache und effektive Möglichkeit, Datenbankprobleme zu erkennen, sind jedoch in einigen Situationen nicht ausreichend. Stellen Sie sich einen Fall vor, in dem Metrikwerte aufgrund eines bekannten Prozesses, z. B. eines täglichen Berichtsauftrags, regelmäßig in ein potenziell problematisches Verhalten steigen. Da solche Spitzen erwartet werden, wäre das Erstellen von Erkenntnissen und Benachrichtigungen für jeden davon konproduktiv und würde wahrscheinlich zu Verschlechterungen bei Warnungen führen.

Es ist jedoch immer noch erforderlich, Spitzen zu erkennen, die sehr ungewöhnlich sind, da Metriken, die viel höher als der Rest oder viel länger sind, echte Probleme mit der Datenbankleistung darstellen könnten. Um dieses Problem zu beheben, DevOpsüberwachtGuru für RDS bestimmte Metriken, um zu erkennen, wann das Verhalten einer Metrik sehr ungewöhnlich oder ungewöhnlich wird. DevOpsGuru meldet diese Anomalien dann in Erkenntnissen.

Beispielsweise DevOpskönnteGuru für RDS einen Einblick geben, wenn die DB-Last nicht nur hoch ist, sondern auch erheblich von ihrem üblichen Verhalten abweicht, was auf eine große unerwartete Verlangsamung der Datenbankoperationen hinweist. Indem Sie nur die ungewöhnlichen DB-Lastspitzen erkennen, können Sie sich mit DevOpsGuru für RDS auf die wirklich wichtigen Probleme konzentrieren.

DB-Last

Das Schlüsselkonzept für die Datenbankoptimierung ist die Datenbanklastmetrik (DB-Last). Die DB-Last gibt an, wie ausgelastet Ihre Datenbank zu einem bestimmten Zeitpunkt ist. Eine Erhöhung der DB-Last bedeutet eine Zunahme der Datenbankaktivität.

Eine Datenbank-Sitzung repräsentiert den Dialog einer Anwendung mit einer relationalen Datenbank. Eine aktive Sitzung ist eine Sitzung, die gerade eine Datenbankanforderung ausführt. Eine Sitzung ist aktiv, wenn sie entweder auf der CPU läuft oder darauf wartet, dass eine Ressource verfügbar wird, damit sie fortfahren kann. Beispielsweise kann eine aktive Sitzung warten, bis eine Seite in den Speicher eingelesen wird, und verbraucht dann CPU, während sie Daten von der Seite liest.

Die DBLoad Metrik in Performance Insights wird in durchschnittlichen aktiven Sitzungen (AAS) gemessen. Um AAS zu berechnen, nimmt Performance Insights Stichproben für die Anzahl der aktiven Sitzungen pro Sekunde. Für einen bestimmten Zeitraum ist der AAS die Gesamtzahl der aktiven Sitzungen geteilt durch die Gesamtzahl der Stichproben. Ein AAS-Wert von 2 bedeutet, dass im Durchschnitt 2 Sitzungen zu einem bestimmten Zeitpunkt in Anfragen aktiv waren.

Eine Analogie zur DB-Last ist die Aktivität in einem Lager. Angenommen, das Lager beschäftigt 100 Mitarbeiter. Wenn eine Bestellung eingeht, erfüllt 1 Mitarbeiter die Bestellung, während die anderen Mitarbeiter im Leerlauf sind. Wenn 100 oder mehr Bestellungen eingehen, erfüllen alle 100 Auftragnehmer gleichzeitig Bestellungen. Wenn Sie regelmäßig prüfen, wie viele Mitarbeiter über einen bestimmten Zeitraum aktiv sind, können Sie die durchschnittliche Anzahl aktiver Mitarbeiter berechnen. Die Berechnung zeigt, dass im Durchschnitt N Arbeitnehmer zu jedem beliebigen Zeitpunkt damit beschäftigt sind, Bestellungen zu erfüllen. Wenn der Durchschnitt gestern 50 Arbeitnehmer und heute 75 Arbeitnehmer betrug, stieg das Aktivitätsniveau im Lager. In gleicher Weise steigt die DB-Last mit zunehmender Sitzungsaktivität.

Weitere Informationen finden Sie unter Datenbanklast im Amazon-Aurora-Benutzerhandbuch oder Datenbanklast im Amazon-RDS-Benutzerhandbuch.

Warteereignisse

Ein Warteereignis ist eine Art der Datenbankinstrumentierung, die Ihnen mitteilt, auf welche Ressource eine Datenbanksitzung wartet, damit sie fortfahren kann. Wenn Performance Insights aktive Sitzungen zur Berechnung der Datenbanklast zählt, werden auch die Warteereignisse aufgezeichnet, die dazu führen, dass die aktiven Sitzungen warten. Mit dieser Technik kann Performance Insights Ihnen zeigen, welche Warteereignisse zur DB-Last beitragen.

Jede aktive Sitzung läuft entweder auf der CPU oder wartet. Sitzungen verbrauchen beispielsweise CPU, wenn sie Speicher suchen, eine Berechnung durchführen oder prozeduralen Code ausführen. Wenn Sitzungen keine CPU verbrauchen, warten sie möglicherweise darauf, dass eine Datendatei gelesen oder ein Protokoll geschrieben wird. Je mehr Zeit eine Sitzung auf Ressourcen wartet, desto weniger Zeit läuft sie auf der CPU.

Wenn Sie eine Datenbank optimieren, versuchen Sie häufig, die Ressourcen zu finden, auf die Sitzungen warten. Beispielsweise könnten zwei oder drei Warteereignisse 90 % der DB-Last ausmachen. Diese Maßnahme bedeutet, dass aktive Sitzungen im Durchschnitt die meiste Zeit damit verbringen, auf eine kleine Anzahl von Ressourcen zu warten. Wenn Sie die Ursache dieser Wartezeiten herausfinden können, können Sie versuchen, das Problem zu beheben.

Betrachten Sie die Analogie eines Lagerarbeiters. Es kommt eine Bestellung für ein Buch. Der Arbeitnehmer kann sich bei der Ausführung der Bestellung verzögern. Beispielsweise könnte ein anderer Auftragnehmer derzeit die Drucker neu auffüllen, oder es ist möglicherweise kein Drucker verfügbar. Oder das System, mit dem der Bestellstatus eingegeben wurde, ist möglicherweise langsam. Je länger der Auftragnehmer wartet, desto länger dauert die Erfüllung der Bestellung. Warten ist ein natürlicher Bestandteil des Lager-Workflows, aber wenn die Wartezeit übermäßig wird, sinkt die Produktivität. Auf die gleiche Weise können wiederholte oder langwierige Sitzungswartungen die Datenbankleistung beeinträchtigen.

Weitere Informationen zu Warteereignissen in Amazon Aurora finden Sie unter Optimieren mit Warteereignissen für Aurora PostgreSQL und Optimieren mit Warteereignissen für Aurora MySQL im Amazon-Aurora-Benutzerhandbuch.

Weitere Informationen zu Warteereignissen in anderen Amazon-RDS-Datenbanken finden Sie unter Optimieren mit Warteereignissen für RDS für PostgreSQL im Amazon-RDS-Benutzerhandbuch.