Mit der Leistungserfassung für Cloud SQL for MySQL können Sie komplexe und vorübergehende Leistungsprobleme in Ihrer MySQL-Datenbank diagnostizieren und beheben, die durch die sich entwickelnde Systemnachfrage verursacht werden. Wenn die Arbeitslasten von Anwendungen skaliert werden und die umgebende Infrastruktur komplexer wird, sind Datenbanken zunehmenden und unvorhersehbaren Anforderungen ausgesetzt. Diese externen Systembelastungen können zu Verlangsamungen oder Stillständen der Datenbank führen.
Wenn die Leistung Ihrer Datenbank nachlässt, reichen Standardmesswerte möglicherweise nicht aus, um die Ursache im Kontext Ihrer größeren Infrastruktur zu ermitteln. Mit der Leistungserfassung wird dieses Problem behoben, indem detaillierte Momentaufnahmen der Datenbank zu dem Zeitpunkt erstellt werden, an dem ein Problem erkannt wird. Sie können konfigurierbare Trigger verwenden, um systemweite Snapshots zu erstellen, wenn vorübergehende Probleme auftreten. Trigger können auch lange andauernde Transaktionen erkennen, die die Ursache von Leistungsproblemen sein können. Sie können Trigger so konfigurieren, dass lange andauernde Transaktionen automatisch beendet werden.
Beispielanwendungsfälle
In diesem Abschnitt werden Beispielanwendungsfälle für die Verwendung der Leistungserfassung aufgeführt, nachdem Sie sie für Ihre Instanz aktiviert haben.
| Anwendungsfall | Triggerbedingung | Diagnoseerkenntnisse |
|---|---|---|
| Systemweite Verlangsamung aufgrund der Anhäufung von Undo-Logs | Länge der Verlaufsliste | Ermittelt, wann der InnoDB-Bereinigungsprozess aufgrund von lang andauernden Lesevorgängen oder großen DML-Vorgängen (Data Manipulation Language, Datenbearbeitungssprache) ins Hintertreffen gerät. Die Verzögerung kann zu erhöhtem Speicherdruck und Leistungseinbußen führen. |
| Datenbankstillstand aufgrund interner Engine-Konflikte | Semaphor-Wartezeiten | Hilfreich bei der Diagnose einer nicht reagierenden Datenbank. Dieser Trigger kann Mutex- oder Lese-/Schreibsperrenkonflikte in der InnoDB-Speicher-Engine erkennen, z. B. Konflikte mit dem adaptiven Hash-Index (Adaptive Hash Index, AHI) oder dem Pufferpool. |
| Sperrenkonflikte auf Anwendungsebene oder nicht indexierte Abfragen | Wartezeiten für Transaktionssperren | Wird ausgelöst, wenn sich eine hohe Anzahl von Transaktionen im Status LOCK WAIT befindet, was auf Konflikte auf Zeilenebene oder lange andauernde inaktive Transaktionen hindeutet. |
| Instanzüberlastung durch komplexe Sortierung oder Aggregation | Hohe CPU-Auslastung | Erfasst den Status bei hoher : CPU-Auslastung des Containers, die oft durch ineffiziente Abfragen oder massive Spitzen bei der Parallelität verursacht wird. |
| Risiko von Neustarts aufgrund von Arbeitsspeichermangel (Out-of-Memory, OOM) | Hohe Arbeitsspeicherauslastung | Hilft Ihnen, Probleme wie zu große Puffer pro Thread oder Arbeitsspeicherlecks zu diagnostizieren, bevor sie zu einem Instanzabsturz führen. |
| Plötzliche Traffic-Spitzen oder Client-Apps mit Engpässen | Ausgeführte Threads | Ein allgemeiner Indikator für die Instanzlast, der nützlich ist, um plötzliche Spitzen bei gleichzeitigen aktiven Verbindungen zu erkennen. |
| Veraltete Daten auf dem Replikat aufgrund hoher Schreibarbeitslasten | Sekunden hinter der Quelle | Überwacht die Replikationsverzögerung auf Lesereplikaten, um Verzögerungen bei der Synchronisierung von Daten von der primären Instanz zu diagnostizieren. |
| Lang andauernde Abfragen, die die Bereinigung blockieren | Lang andauernde Transaktionen | Ermittelt Transaktionen, die zu lange geöffnet sind und möglicherweise kritische Sperren enthalten. Außerdem können Sie lange andauernde Transaktionen automatisch beenden. |
Erfassung von Leistungsdaten
Die Leistungserfassung funktioniert als agentbasierter Dienst, der Ihre Instanz überwacht. Wenn Sie die Leistungserfassung aktivieren, führt Ihre Cloud SQL-Instanz die folgenden Schritte aus, um Leistungsdaten zu erfassen:
Der Agent prüft Ihre Instanzkonfiguration, um die von Ihnen definierten schwellenwertbasierten Trigger zu lesen. Anschließend prüft der Agent die Messwerte Ihrer Instanz in einem konfigurierbaren Intervall (
probingIntervalSeconds), das standardmäßig auf 30 Sekunden festgelegt ist.Wenn ein Problem erkannt wird und der Schwellenwert eines Triggers überschritten wurde, vergleicht der Agent den Live-Status der Instanz weiterhin mit Ihren Regeln. Um Fehlalarme durch vorübergehende Spitzen zu vermeiden, löst der Agent eine vollständige Leistungserfassung aus. Eine Erfassung wird nur ausgelöst, wenn die Bedingung bei aufeinanderfolgenden Prüfungen für den konfigurierten
probeThresholderfüllt ist, der standardmäßig auf3festgelegt ist. Dieser aufeinanderfolgende Schwellenwert verhindert Erfassungen aufgrund vorübergehender Spitzen.Der Agent kann beispielsweise eine Leistungserfassung auslösen, wenn er erkennt, dass die Anzahl der Threads bei drei Prüfungen in Folge hoch ist.
Wenn mehrere Triggerbedingungen konfiguriert sind, initiiert Cloud SQL eine Erfassung, wenn eine der Bedingungen erfüllt ist.
Wenn eine Erfassung ausgelöst wird, stellt die Leistungserfassung eine Verbindung zur Datenbank her und führt eine Reihe von Diagnosebefehlen aus, um einen detaillierten Snapshot zu erstellen.
Die erfassten Informationen werden in Logeinträge formatiert und direkt an Cloud Logging des Projekts für die Cloud SQL-Instanz unter einem bestimmten Logstream mit dem Namen
mysql-performance-capture.loggesendet.
Abkühlungs- und adaptive Backoff-Zeiträume
Um übermäßiges Logging und System-Overhead zu vermeiden, implementiert die Leistungserfassung nach einer Erfassung einen Abkühlungszeitraum.
Standardabkühlung
Nach einer erfolgreichen Erfassung startet die Leistungserfassung eine 30-minütige Standardabkühlung. Während dieser Zeit löst der Agent keine neuen Erfassungen aus, auch wenn sich die Instanz in einem längeren Problemzustand befindet.
Adaptive Abkühlung und Backoff
Wenn eine Instanz wiederholt Erfassungen für denselben Verstoß auslöst, verwendet die Leistungserfassung einen adaptiven Backoff-Mechanismus für die Abkühlung. Dieser Mechanismus hilft, das Logging-Volumen und die Kosten für falsch konfigurierte Schwellenwerte zu begrenzen.
Bei diesem Mechanismus gilt Folgendes:
- Die Wartezeit wird auf 24 Stunden verlängert.
- Die Leistungserfassung wechselt in den Schlafmodus, in dem alle Trigger prüfungen und Diagnoseerfassungen angehalten werden.
- Die Instanz ist auf eine Leistungserfassung pro Tag beschränkt.
Trigger für die Leistungserfassung
In diesem Abschnitt werden die Trigger aufgeführt, die für die MySQL-Leistungserfassung verfügbar sind. Alle in der Tabelle aufgeführten Trigger verwenden, sofern nicht anders angegeben, die Werte der Prüfkonfiguration probingIntervalSeconds und probeThreshold, um anhaltende Triggerbedingungen zu validieren.
| Trigger bedingungs name | API-Name | Beschreibung | Standard wert | Konfigurations bereich |
|---|---|---|---|---|
| Hohe CPU Auslastung |
cpuUtilizationThresholdPercent
|
Löst eine Erfassung aus, wenn die Gesamt-CPU-Auslastung der Datenbankinstanz diesen Prozentsatz dauerhaft überschreitet. So können Sie eine Instanzüberlastung erkennen, die oft durch ineffiziente Abfragen mit massiver Sortierung und Aggregation, unzureichende Indexierung oder sehr hohe Parallelität verursacht wird. Um Erfassungen bei kleineren Spitzen zu vermeiden, konfigurieren Sie den Standardwert so, dass er im höheren Prozentbereich für Ihre Instanz liegt. | 0 (deaktiviert)
|
0 oder 10–99 (%)
|
| Hohe Arbeitsspeicher- Auslastung |
memoryUsageThresholdPercent
|
Löst eine Erfassung aus, wenn die Arbeitsspeicherauslastung des Datenbankcontainers diesen Prozentsatz des zugewiesenen Arbeitsspeichers der Instanz dauerhaft überschreitet. Mit diesem Trigger können Sie potenzielle Probleme mit Arbeitsspeichermangel, Arbeitsspeicherlecks oder einer ineffizienten Arbeitsspeicherkonfiguration diagnostizieren. Um die Erfassung kleinerer Spitzen zu vermeiden, legen Sie den Standardwert am oberen Ende des Bereichs für Ihre Instanz fest. | 0 (deaktiviert)
|
0 oder 10–99 (%)
|
| Hohe Nutzung temporärer Dateien |
Nicht konfigurierbar Dieser Trigger ist für MySQL 8.0 und höher automatisch aktiviert. | Löst automatisch eine Erfassung aus, wenn die Festplattennutzung durch die vom MySQL-Prozess erstellten temporären Dateien erheblich ansteigt.
Oft werden temporäre Dateien gelöscht, sind aber weiterhin von einem MySQL-Prozess geöffnet. Der Schwellenwert für diesen Trigger verwendet ein progressives Eskalationsmodell für unterschiedliche Schwellenwerte. Er beginnt bei 100 GB und verdoppelt sich nach jeder Abkühlung sequenziell auf 200 GB, 400 GB und bis zu 1,6 TB. Durch die Verwendung eines progressiven Eskalationsmodells erfolgt die Leistungserfassung nur, wenn der Unterschied bei der Nutzung temporärer Dateien stark ansteigt. |
Aktiviert | – |
| Länge der Verlaufsliste |
historyListLengthThresholdCount
|
Löst eine Erfassung aus, wenn die Länge der InnoDB-Verlaufsliste (History List Length, HLL) den konfigurierten Wert überschreitet. Eine dauerhaft hohe HLL deutet darauf hin, dass der InnoDB-Bereinigungsprozess nicht mithalten kann und die Anzahl der nicht bereinigten Transaktionen zunimmt, oft aufgrund von lang andauernden Transaktionen. Diese hohe Anzahl kann zu einem erhöhten Speicherverbrauch und Leistungsproblemen führen. Dieser Schwellenwert ist von der Arbeitslast abhängig. Einige Instanzen können auch bei einer dauerhaft hohen HLL ausreichend funktionieren. Sie können diesen Trigger jedoch verwenden, um potenzielle Probleme wie lang andauernde Lesevorgänge, große DML-Anweisungen (Data Manipulation Language, Datenbearbeitungssprache) oder Engpässe bei Bereinigungs-Threads hervorzuheben. |
0 (deaktiviert)
|
0 oder 10000–10000000
|
| Lang andauernde Transaktionen |
transactionDurationThreshold
|
Eine Transaktion wird protokolliert, wenn sie länger als die konfigurierte Dauer in Sekunden ausgeführt wird. Dieser Trigger ist nützlich, um Vorgänge zu identifizieren, die Sperren übermäßig lange aufrechterhalten oder Ressourcen zu lange nutzen. Transaktionen, die transactionDurationThreshold überschreiten, werden nach jedem Intervall ausgewertet, das in der Konfiguration probingIntervalSeconds angegeben ist (Standardwert: 30 Sekunden). Um das Logvolumen zu verwalten, werden die Details von bis zu 10 dieser lang andauernden Transaktionen jedoch höchstens einmal pro Wartefrist (30 Minuten) an Cloud Logging gesendet.
Der vollständige Abfragetext von bis zu 1024 Byte aus INFORMATION_SCHEMA.INNODB_TRX ist in jedem Logeintrag für die 10 wichtigsten Transaktionen enthalten. |
3600 (Sekunden)
|
60 oder mehr
|
| Fehler im SQL-/IO- Thread des Replikats |
Nicht konfigurierbar Dieser Trigger ist standardmäßig automatisch auf allen Replikatinstanzen aktiviert und kann nicht deaktiviert werden. | Löst sofort eine Erfassung aus, wenn im SQL- oder IO-Thread der Replikation auf einer Replikatinstanz ein Fehler auftritt und der Thread beendet wird. Dieser Trigger ist entscheidend, um die Integrität des Replikats aufrechtzuerhalten und Replikationsfehler zu erkennen. Dieser Trigger verwendet keine Einstellungen für die Prüfkonfiguration wie probingIntervalseconds oder probeThreshold, um die Bedingungen für die Leistungserfassung zu validieren. |
Aktiviert | – |
| Ausgeführte Threads | runningThreadsThreshold
|
Löst eine Erfassung aus, wenn die Anzahl der aktiven Threads, die auf der Grundlage der Statusvariablen threads_running ausgeführt werden, den angegebenen Wert überschreitet. Sie können den Schwellenwert beispielsweise so konfigurieren, dass die Leistungserfassung ausgeführt wird, wenn die Anzahl der aktiven Threads 100 übersteigt.Dieser Trigger ist für die Leistungserfassung erforderlich. Wenn Sie diesen Trigger nicht explizit konfigurieren, wird der Standardwert anhand der Anzahl der vCPUs berechnet, die zur Instanz gehören. |
MIN(600,
cpuCount * 20)
|
10 oder mehr
|
| Sekunden hinter Quelle |
secondsBehindSourceThreshold
|
Löst eine Erfassung aus, wenn die Replikationsverzögerung auf der Lesereplikatinstanz, gemessen in Sekunden, den angegebenen Wert überschreitet. Mit diesem Trigger können Sie Verzögerungen bei der Replikation überwachen und diagnostizieren. Dieser Trigger ist für Replikatinstanzen automatisch aktiviert. Wenn Sie den Trigger nicht explizit konfigurieren, beträgt der Standardwert 900 Sekunden. Wir empfehlen, den Wert am oberen Ende zu konfigurieren, um übermäßige Erfassungen und häufige Abkühlungen zu vermeiden. | 900 (Sekunden)
|
1 oder mehr
|
| Semaphor-Wartezeiten | semaphoreWaitThresholdCount
|
Löst eine Erfassung aus, wenn die Anzahl der Threads, die auf interne InnoDB-Semaphore warten, den konfigurierten Wert dieses Triggers überschreitet. Dieser erweiterte Messwert gibt Konflikte an, die entweder durch eine Mutex- oder eine Lese-/Schreibsperre innerhalb der InnoDB-Speicher-Engine selbst verursacht werden.
Die üblichen Konflikte sind Konflikte mit dem adaptiven Hash-Index (Adaptive Hash Index, AHI), Konflikte mit dem Pufferpool und Konflikte mit der Festplatten-E/A. Eine Erfassung wird auch ausgelöst, wenn die maximale Wartezeit für ein einzelnes Semaphor 200 Sekunden überschreitet, unabhängig vom konfigurierten Wert dieses Triggers. |
0 (deaktiviert)
|
0 oder 10–10000
|
| Wartezeiten für Transaktionssperren |
transactionLockWaitThresholdCount
|
Löst eine Erfassung aus, wenn die Anzahl der Transaktionen im Status LOCK WAIT die konfigurierte Anzahl überschreitet. Eine kleine Anzahl von Transaktionen im Status „Warten auf Sperre“ kann in einem ausgelasteten System normal sein. Eine dauerhaft hohe Anzahl von Wartezeiten für Sperren ist jedoch ein starker Indikator für Sperrenkonflikte auf Anwendungsebene, nicht indexierte DML-Anweisungen, lange inaktive Transaktionen und Konflikte auf Zeilenebene mit hoher Nebenläufigkeit, die die Leistung und den Durchsatz erheblich beeinträchtigen können. |
0 (deaktiviert)
|
0 oder 10–10000
|
Preise
Die Leistungserfassung ist in allen Cloud SQL-Regionen ohne zusätzliche Kosten verfügbar. Standardgebühren fallen nur für die zugrunde liegenden Datenbankressourcen an. Bei der Leistungserfassung werden Logs in Cloud Logging gespeichert, was zusätzliche Speicherkosten für Cloud Logging verursachen kann.
Weitere Informationen zu den Preisen für das Speichern von Logs in Cloud Logging, finden Sie unter Preise.
Beschränkungen
- Sie müssen Query Insights aktivieren , um die Leistungserfassung verwenden zu können. Wenn Sie Query Insights deaktivieren, wird auch die Leistungserfassung deaktiviert.
- Die Leistungserfassung ist nur für Cloud SQL for MySQL 5.7 und höher verfügbar.