Auf dieser Seite wird beschrieben, wie Sie mit dem Query Insights-Dashboard Leistungsprobleme erkennen und analysieren.
Sie können die Unterstützung von Gemini in Datenbanken verwenden, um Ihre Cloud SQL for PostgreSQL-Ressourcen zu beobachten und Fehler zu beheben. Weitere Informationen finden Sie unter Mit Gemini in Datenbanken beobachten und Fehler beheben.
Einführung
Mit Query Insights können Sie Probleme bei der Abfrageleistung in Cloud SQL-Datenbanken ermitteln, diagnostizieren und verhindern. Es unterstützt ein intuitives Monitoring und liefert Diagnoseinformationen, die Ihnen helfen, über die Erkennung hinaus die Ursache von Leistungsproblemen zu identifizieren.
Mit Query Insights können Sie die Leistung auf Anwendungsebene überwachen und die Quelle einer problematischen Abfrage im gesamten Anwendungspaket nach Modell, Ansicht, Controller, Route, Nutzer und Host verfolgen. Das Query Insights-Tool lässt sich mit offenen Standards und APIs in Ihre vorhandenen Tools zur Anwendungsüberwachung (APM) und in Google Cloud Dienste einbinden. So können Sie Abfrageprobleme mit Ihrem Lieblingstool überwachen und beheben.
Mit Query Insights können Sie die Leistung von Cloud SQL-Abfragen verbessern. Dabei werden Sie durch die folgenden Schritte geführt:
- Datenbanklast für Top-Abfragen ansehen
- Potenziell problematische Abfrage oder potenziell problematisches Tag identifizieren
- Abfrage oder Tag ansehen, um Probleme zu ermitteln
- Ursache des Problems ermitteln
Statistiken für Cloud SQL Enterprise Plus-Version abfragen
Wenn Sie Cloud SQL Enterprise Plus verwenden, können Sie in den Abfragestatistiken auf zusätzliche Funktionen zugreifen, um erweiterte Diagnosen zur Abfrageleistung durchzuführen. Zusätzlich zu den Standardfunktionen des Dashboards „Abfragestatistiken“ können Sie mit Query Insights für die Cloud SQL Enterprise Plus-Version Folgendes tun:
- Warteereignisse für alle ausgeführten Abfragen erfassen und analysieren
- Aggregierte Datenbanklast nach zusätzlichen Dimensionen wie Abfragen, Tags und Warteereignistypen filtern
- Abfragepläne für alle ausgeführten Abfragen erfassen
- Bis zu 200 Abfragepläne pro Minute erfassen
- Längerer Abfragetext bis zu 100 KB
- Aktualisierungen für Messwerte nahezu in Echtzeit (innerhalb weniger Sekunden) erhalten
- Längere Aufbewahrungsdauer von Messwerten über 30 Tage
In der folgenden Tabelle werden die funktionalen Anforderungen und Funktionen von Query Insights für die Cloud SQL Enterprise-Version mit Query Insights für die Cloud SQL Enterprise Plus-Version verglichen.
Vergleichsbereich | Query Insights für die Cloud SQL Enterprise-Version | Statistiken für Cloud SQL Enterprise Plus-Version abfragen |
---|---|---|
Unterstützte Datenbankversionen | PostgreSQL 9.6 oder höher | PostgreSQL 12 oder höher |
Unterstützte Maschinentypen | Unterstützt auf allen Maschinentypen | Nicht unterstützt für Instanzen mit Maschinentypen mit gemeinsam genutztem Kern oder Lesereplikate |
Unterstützte Regionen | Standortorte von Cloud SQL | Standortorte für die Cloud SQL Enterprise Plus-Version |
Aufbewahrungsdauer von Messwerten | 7 Tage | 30 Tage |
Maximale Abfragelänge | 4.500 Byte | 100 KB |
Maximale Anzahl von Abfrageplanstichproben | 20 | 200 |
Analyse von Warteereignissen | Nicht verfügbar | Verfügbar |
Wenn Sie Abfragestatistiken für die Cloud SQL Enterprise Plus-Version während der Vorabversion für Ihre Cloud SQL Enterprise Plus-Instanz aktivieren möchten, folgen Sie der Anleitung unter Abfragestatistiken für die Cloud SQL Enterprise Plus-Version aktivieren.
Preise
Für Query Insights fallen keine zusätzlichen Kosten an. Außerdem ist es kostenlos, Abfragestatistiken für die Cloud SQL Enterprise Plus-Version zu aktivieren, die sich derzeit in der Vorabversion befindet.
Speicherbedarf
Query Insights für die Cloud SQL Enterprise-Version belegt keinen Speicherplatz in Ihrem Cloud SQL-Instanzspeicher. Messwerte werden in Cloud Monitoring gespeichert. Informationen zu API-Anfragen finden Sie unter Cloud Monitoring-Preise. Cloud Monitoring bietet eine Stufe, die Sie ohne zusätzliche Kosten nutzen können.
Bei Abfragestatistiken für die Cloud SQL Enterprise Plus-Version (Vorabversion) werden Messwertdaten auf demselben Laufwerk gespeichert, das mit Ihrer Cloud SQL-Instanz verbunden ist. Außerdem muss die Einstellung für automatische Speichererweiterungen aktiviert bleiben.
Für sieben Tage an Daten ist ein Speicherplatz von etwa 36 GB erforderlich. Für 30 Tage benötigen Sie etwa 155 GB. Query Insights für die Cloud SQL Enterprise Plus-Version benötigt bis zu 10 MB RAM (gemeinsam genutzter Arbeitsspeicher). Messwerte sollten innerhalb von 30 Sekunden nach Abschluss der Abfrage in Query Insights verfügbar sein. Es fallen die geltenden Speichergebühren an.Hinweis
Führen Sie die folgenden Schritte aus, bevor Sie Suchanfrage-Statistiken verwenden:
- Fügen Sie die erforderlichen Rollen und Berechtigungen hinzu.
- Aktivieren Sie die Cloud Trace API.
- Wenn Sie Abfragestatistiken für die Cloud SQL Enterprise Plus-Version verwenden, muss Automatische Speichererweiterungen aktivieren für die Instanz aktiviert sein.
Erforderliche Rollen und Berechtigungen
Wenn Sie Suchanfrage-Statistiken verwenden möchten, müssen Sie Rollen mit den erforderlichen Identity and Access Management-Berechtigungen gewähren oder einem Nutzerkonto die erforderlichen Berechtigungen zuweisen.
Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff verwalten.
Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für das Projekt zuzuweisen, in dem die Cloud SQL-Instanz gehostet wird, um die Berechtigungen zu erhalten, die Sie zum Zugriff auf Verlaufsdaten zur Abfrageausführung im Dashboard „Abfragestatistiken“ benötigen:
-
Database Insights-Monitoring-Betrachter (
roles/databaseinsights.monitoringViewer
) -
Cloud SQL-Betrachter (
roles/cloudsql.viewer
)
Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.
Diese vordefinierten Rollen enthalten die Berechtigungen, die zum Zugriff auf Verlaufsdaten zur Abfrageausführung im Dashboard „Abfragestatistiken“ erforderlich sind. Erweitern Sie den Abschnitt Erforderliche Berechtigungen, um die erforderlichen Berechtigungen anzuzeigen:
Erforderliche Berechtigungen
Die folgenden Berechtigungen sind erforderlich, um auf Verlaufsdaten zur Abfrageausführung im Dashboard „Abfragestatistiken“ zuzugreifen:
-
databaseinsights.aggregatedStats.query
-
databaseinsights.timeSeries.query
Sie können diese Berechtigungen auch mit benutzerdefinierten Rollen oder anderen vordefinierten Rollen erhalten.
In Database Insights können Sie Ihren Administrator beispielsweise bitten, Ihnen die vordefinierte Rolle Database Insights Viewer (roles/databaseinsights.viewer
) zuzuweisen. Anschließend können Sie Ihren Administrator in Cloud SQL bitten, Ihnen eine der folgenden vordefinierten Rollen zu gewähren:
- Cloud SQL-Bearbeiter (
roles/cloudsql.editor
) - Cloud SQL-Administrator (
roles/cloudsql.admin
)
Trace API aktivieren
Wenn Sie Abfragepläne und ihre End-to-End-Ansichten aufrufen möchten, muss in Ihrem Google Cloud Projekt die Trace API aktiviert sein. Mit dieser Einstellung kann IhrGoogle Cloud -Projekt ohne zusätzliche Kosten Trace-Daten von authentifizierten Quellen empfangen. Anhand dieser Daten können Sie Leistungsprobleme in Ihrer Instanz erkennen und diagnostizieren.
So prüfen Sie, ob die Trace API aktiviert ist:
- Rufen Sie in der Google Cloud Console APIs und Dienste auf:
- Klicken Sie auf APIs und Dienste aktivieren.
- Geben Sie in der Suchleiste
Trace API
ein. - Wenn API aktiviert angezeigt wird, ist diese API aktiviert und Sie müssen nichts tun. Klicken Sie andernfalls auf Aktivieren.
Automatische Speichererhöhungen aktivieren
Wenn Sie Abfragestatistiken für die Cloud SQL Enterprise Plus-Version (Vorabversion) verwenden, muss die Instanzeinstellung automatische Speichererweiterungen aktivieren aktiviert bleiben. Diese Option ist standardmäßig für Cloud SQL-Instanzen aktiviert.Wenn Sie diese Instanzeinstellung zuvor deaktiviert haben und Abfragestatistiken für die Cloud SQL Enterprise Plus-Version aktivieren möchten, müssen Sie zuerst die automatische Speichererweiterung wieder aktivieren. Sie können die automatische Speichererweiterung nicht deaktivieren und Abfragestatistiken für die Cloud SQL Enterprise Plus-Version aktivieren.
Abfragestatistiken aktivieren
Nutzer mit Zugriff auf das Cloud SQL-Dashboard können auf Query Insights-Messwerte zugreifen. Wenn Sie berechtigt sind, Instanzen zu aktualisieren, können Sie Query Insights aktivieren. Eine Liste der für Cloud SQL-Instanzen erforderlichen Berechtigungen finden Sie unter Cloud SQL-Projektzugriffssteuerung. Wenn Sie diese Berechtigungen nicht haben und Query Insights für Ihre Instanzen aktivieren möchten, wenden Sie sich an Ihren Administrator.
Abfragestatistiken für eine Instanz aktivieren
-
Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.
- Klicken Sie auf den Instanznamen, um die Übersichtsseite einer Instanz zu öffnen.
- Klicken Sie in der Kachel Konfiguration auf Konfiguration bearbeiten.
- Maximieren Sie im Bereich Instanz anpassen den Eintrag Abfragestatistiken.
- Klicken Sie das Kästchen Query Insights aktivieren an.
- Optional. Wählen Sie eine oder mehrere der folgenden zusätzlichen Funktionen für Abfragestatistiken aus:
- Klicken Sie auf Speichern.
Analyse aktiver Abfragen
Standardwert: false
Hier können Sie Details zu Ihren aktiv ausgeführten Abfragen prüfen und bei Bedarf lang laufende Abfragen beenden. Weitere Informationen finden Sie unter Aktive Abfragen überwachen. Diese Funktion befindet sich im Vorabzugriff.
Indexberater aktivieren
Standardwert: false
Der Indexberater gibt Indexempfehlungen, um die Abfrageverarbeitung zu beschleunigen. Wenn Sie den Indexberater aktivieren, muss die Instanz neu gestartet werden. Weitere Informationen finden Sie unter Übersicht Indexberater und Indexberater verwenden. Diese Funktion befindet sich im Vorabzugriff.
Client-IP-Adressen speichern
Standardwert: false
Speichert die Client-IP-Adressen, von denen Abfragen stammen, und hilft Ihnen, diese Daten zu gruppieren, um Messwerte damit auszuführen. Abfragen stammen von mehr als einem Host. Anhand der Grafiken zu Abfragen von Client-IP-Adressen können Sie die Ursache eines Problems ermitteln.
Anwendungstags speichern
Standardwert: false
Speichert Anwendungs-Tags, die Ihnen dabei helfen, die APIs und MVC-Routen (Model-View-Controller) zu bestimmen, die Anfragen stellen, und die Daten zu gruppieren, um sie mit Messwerten zu vergleichen. Bei dieser Option müssen Sie Abfragen mit einer bestimmten Gruppe von Tags mithilfe der Open-Source-Bibliothek für die objektrelationale Zuordnung (ORM) der sqlcommenter-Funktion kommentieren. Diese Informationen helfen Query Insights, die Ursache eines Problems und den MVC zu ermitteln, von dem das Problem stammt. Anwendungspfade unterstützen Sie beim Anwendungsmonitoring.
Abfragelänge anpassen
Standardwert: 1024
Legt die maximale Länge der Abfrage auf einen angegebenen Wert von 256 Byte bis 4.500 Byte fest. Höhere Abfragelängen sind hilfreich für analytische Abfragen, erfordern aber auch mehr Arbeitsspeicher. Zum Ändern der Abfragelänge müssen Sie die Instanz neu starten. Sie können weiterhin Tags zu Abfragen hinzufügen, die die Längenbegrenzung überschreiten.
Maximale Abtastrate festlegen
Standardwert: 5
Legt die maximale Abtastrate fest. Die Abtastrate ist die Anzahl der ausgeführten Abfrageplanstichproben, die pro Minute in allen Datenbanken der Instanz erfasst werden. Ändern Sie diesen Wert in eine Zahl von 0 (Probenahme deaktiviert) bis 20. Wenn Sie die Abtastrate erhöhen, erhalten Sie wahrscheinlich mehr Datenpunkte. Allerdings kann dies zu Leistungseinbußen führen.
Query Insights für mehrere Instanzen aktivieren
-
Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.
- Klicken Sie in einer beliebigen Zeile auf das Dreipunkt-Menü .
- Wählen Sie Abfragestatistiken aktivieren aus.
- Klicken Sie im Dialogfeld auf das Kästchen Query Insights für mehrere Instanzen aktivieren.
- Klicken Sie auf Aktivieren.
- Wählen Sie im nachfolgenden Dialogfeld die Instanzen aus, für die Sie Query Insights aktivieren möchten.
- Klicken Sie auf Query Insights aktivieren.
Um Query Insights für eine Cloud SQL-Instanz mithilfe von gcloud
zu aktivieren, führen Sie gcloud sql instances patch
mit dem Flag --insights-config-query-insights-enabled
so aus, nachdem Sie INSTANCE_ID durch die ID der Instanz ersetzt haben.
gcloud sql instances patchINSTANCE_ID \ --insights-config-query-insights-enabled
Verwenden Sie außerdem eines oder mehrere der folgenden optionalen Flags:
--insights-config-record-client-address
Speichert die Client-IP-Adressen, von denen Abfragen stammen, und hilft Ihnen, diese Daten zu gruppieren, um Messwerte damit auszuführen. Abfragen stammen von mehr als einem Host. Anhand der Grafiken zu Abfragen von Client-IP-Adressen können Sie die Ursache eines Problems ermitteln.
--insights-config-record-application-tags
Speichert Anwendungs-Tags, die Ihnen dabei helfen, die APIs und MVC-Routen (Model-View-Controller) zu bestimmen, die Anfragen stellen, und die Daten zu gruppieren, um sie mit Messwerten zu vergleichen. Bei dieser Option müssen Abfragen mit einem bestimmten Satz von Tags kommentiert werden. Dazu können Sie die Open-Source-Bibliothek für die objektrelationale Zuordnung (ORM) der sqlcommenter-Funktion verwenden. Diese Informationen helfen Query Insights, die Ursache eines Problems und den MVC zu ermitteln, von dem das Problem stammt. Anwendungspfade unterstützen Sie beim Anwendungsmonitoring.
--insights-config-query-string-length
Legt die maximale Länge der Abfragelänge auf einen angegebenen Wert von 256 bis 4.500 Byte fest. Die Standardlänge der Abfrage beträgt 1.024 Byte. Höhere Abfragelängen sind hilfreich für analytische Abfragen, erfordern aber auch mehr Arbeitsspeicher. Zum Ändern der Abfragelänge müssen Sie die Instanz neu starten. Sie können weiterhin Tags zu Abfragen hinzufügen, die die Längenbegrenzung überschreiten.
--query_plans_per_minute
Standardmäßig werden in allen Datenbanken der Instanz maximal 5 ausgeführte Abfrageplanstichproben pro Minute erfasst. Ändern Sie diesen Wert in eine Zahl von 0 (Probenahme deaktiviert) bis 20. Wenn Sie die Abtastrate erhöhen, erhalten Sie wahrscheinlich mehr Datenpunkte. Allerdings kann dies zu Leistungseinbußen führen.
Ersetzen Sie Folgendes:
- INSIGHTS_CONFIG_QUERY_STRING_LENGTH: Die zu speichernde Länge des Abfragestrings in Byte.
- API_TIER_STRING: Die benutzerdefinierte Instanzkonfiguration, die für die Instanz verwendet werden soll.
- REGION: Die Region für die Instanz.
gcloud sql instances patchINSTANCE_ID \ --insights-config-query-insights-enabled \ --insights-config-query-string-length=INSIGHTS_CONFIG_QUERY_STRING_LENGTH \ --query_plans_per_minute=QUERY_PLANS_PER_MINUTE \ --insights-config-record-application-tags \ --insights-config-record-client-address \ --tier=API_TIER_STRING \ --region=REGION
Rufen Sie die Methode instances.patch
mit den Einstellungen für insightsConfig
auf, um Query Insights für eine Cloud SQL-Instanz mithilfe der REST API zu aktivieren.
Ersetzen Sie diese Werte in den folgenden Anfragedaten:
- project-id: die Projekt-ID
- instance-id: Die Instanz-ID.
HTTP-Methode und URL:
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id /instances/instance-id
JSON-Text anfordern:
{ "settings" : { "insightsConfig" : { "queryInsightsEnabled" : true } } }
Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:
curl (Linux, macOS oder Cloud Shell)
Speichern Sie den Anfragetext in einer Datei mit dem Namen request.json
und führen Sie den folgenden Befehl aus:
curl -X PATCH \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json; charset=utf-8" \
-d @request.json \
"https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id /instances/instance-id "
PowerShell (Windows)
Speichern Sie den Anfragetext in einer Datei mit dem Namen request.json
und führen Sie den folgenden Befehl aus:
$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }
Invoke-WebRequest `
-Method PATCH `
-Headers $headers `
-ContentType: "application/json; charset=utf-8" `
-InFile request.json `
-Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id /instances/instance-id " | Select-Object -Expand Content
Sie sollten eine JSON-Antwort ähnlich wie diese erhalten:
{ "kind": "sql#operation", "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id /instances/instance-id ", "status": "PENDING", "user": "user@example.com", "insertTime": "2021-01-28T22:43:40.009Z", "operationType": "UPDATE", "name": "operation-id ", "targetId": "instance-id ", "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id /operations/operation-id ", "targetProject": "project-id " }
Wenn Sie Terraform verwenden möchten, um Query Insights für eine Cloud SQL-Instanz zu aktivieren, legen Sie das Flag query_insights_enabled
auf true
fest.
Sie können auch eines oder mehrere der folgenden optionalen Flags verwenden:
-
query_string_length
: Der Standardwert ist1024
und Sie können einen Wert zwischen256
und4500
in Byte konfigurieren. -
record_application_tags
: Setzen Sie den Wert auftrue
, wenn Sie Anwendungs-Tags aus der Abfrage aufzeichnen möchten. -
record_client_address
: Setzen Sie den Wert auftrue
, wenn Sie die Client-IP-Adresse erfassen möchten. -
query_plans_per_minute
: Der Standardwert ist5
und Sie können einen Wert zwischen5
und20
konfigurieren.
Beispiel:
resource "google_sql_database_instance" "INSTANCE_NAME " { name = "INSTANCE_NAME " database_version = "POSTGRESQL_VERSION " region = "REGION " root_password = "PASSWORD " deletion_protection = false # set to true to prevent destruction of the resource settings { tier = "DB_TIER " insights_config { query_insights_enabled = true query_string_length = 2048 # Optional record_application_tags = true # Optional record_client_address = true # Optional query_plans_per_minute = 10 # Optional } } }
Führen Sie die Schritte in den folgenden Abschnitten aus, um Ihre Terraform-Konfiguration auf ein Google Cloud-Projekt anzuwenden.
Cloud Shell vorbereiten
- Rufen Sie Cloud Shell auf.
-
Legen Sie das Google Cloud-Standardprojekt fest, auf das Sie Ihre Terraform-Konfigurationen anwenden möchten.
Sie müssen diesen Befehl nur einmal pro Projekt und in jedem beliebigen Verzeichnis ausführen.
export GOOGLE_CLOUD_PROJECT=
PROJECT_ID Umgebungsvariablen werden überschrieben, wenn Sie in der Terraform-Konfigurationsdatei explizite Werte festlegen.
Verzeichnis vorbereiten
Jede Terraform-Konfigurationsdatei muss ein eigenes Verzeichnis haben (auch als Stammmodul bezeichnet).
-
Erstellen Sie in Cloud Shell ein Verzeichnis und eine neue Datei in diesem Verzeichnis. Der Dateiname muss die Erweiterung
.tf
haben, z. B.main.tf
. In dieser Anleitung wird die Datei alsmain.tf
bezeichnet.mkdir
DIRECTORY && cdDIRECTORY && touch main.tf -
Wenn Sie einer Anleitung folgen, können Sie den Beispielcode in jedem Abschnitt oder Schritt kopieren.
Kopieren Sie den Beispielcode in das neu erstellte
main.tf
.Kopieren Sie optional den Code aus GitHub. Dies wird empfohlen, wenn das Terraform-Snippet Teil einer End-to-End-Lösung ist.
- Prüfen und ändern Sie die Beispielparameter, die auf Ihre Umgebung angewendet werden sollen.
- Speichern Sie die Änderungen.
-
Initialisieren Sie Terraform. Dies ist nur einmal für jedes Verzeichnis erforderlich.
terraform init
Fügen Sie optional die Option
-upgrade
ein, um die neueste Google-Anbieterversion zu verwenden:terraform init -upgrade
Änderungen anwenden
-
Prüfen Sie die Konfiguration und prüfen Sie, ob die Ressourcen, die Terraform erstellen oder aktualisieren wird, Ihren Erwartungen entsprechen:
terraform plan
Korrigieren Sie die Konfiguration nach Bedarf.
-
Wenden Sie die Terraform-Konfiguration an. Führen Sie dazu den folgenden Befehl aus und geben Sie
yes
an der Eingabeaufforderung ein:terraform apply
Warten Sie, bis Terraform die Meldung „Apply complete“ anzeigt.
- Öffnen Sie Ihr Google Cloud-Projekt, um die Ergebnisse aufzurufen. Rufen Sie in der Google Cloud Console Ihre Ressourcen in der Benutzeroberfläche auf, um sicherzustellen, dass Terraform sie erstellt oder aktualisiert hat.
Messwerte sollten innerhalb von Minuten nach Abschluss der Abfrage in Query Insights verfügbar sein. Sehen Sie sich die Datenaufbewahrungsrichtlinie für Cloud Monitoring an.
Query Insights-Traces werden in Cloud Trace gespeichert. Sehen Sie sich die Cloud Trace-Datenaufbewahrungsrichtlinie an.
Abfragestatistiken für Cloud SQL Enterprise Plus-Version aktivieren
Sie können Query Insights für die Cloud SQL Enterprise Plus-Version nur in Ihrer Cloud SQL-Instanz mithilfe der Google Cloud Console aktivieren.
-
Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.
- Klicken Sie auf den Instanznamen, um die Übersichtsseite einer Instanz zu öffnen.
- Klicken Sie auf Bearbeiten.
- Prüfen Sie im Bereich Speicher, ob das Kästchen Automatische Speichererweiterungen aktivieren angeklickt ist.
- Maximieren Sie im Bereich Instanz anpassen den Eintrag Abfragestatistiken.
- Klicken Sie das Kästchen Enterprise Plus-Funktionen aktivieren an.
Nachdem Sie Abfragestatistiken für die Cloud SQL Enterprise Plus-Version aktiviert haben, können Sie die folgenden Felder aktualisieren:
Abfragelänge anpassen: Hier können Sie die maximale Abfragelänge in Byte angeben. Sie können eine Zahl zwischen
Standardmäßig beträgt die maximale Stichprobenrate 200 Abfrageplanstichproben pro Minute in allen Datenbanken der Instanz.1024
und100000
angeben. Alle Suchstrings, die das angegebene Limit überschreiten, werden bei der Anzeige abgeschnitten. Ein höheres Limit für die Abfragelänge erfordert mehr Arbeitsspeicher. Der Standardwert ist10000
Byte.
Klicken Sie auf Speichern.
Query Insights-Dashboard ansehen
Im Query Insights-Dashboard wird die Abfragelast basierend auf von Ihnen ausgewählten Faktoren angezeigt. Die Abfragelast ist ein Maß für die Gesamtarbeit aller Abfragen in der Instanz im ausgewählten Zeitraum. Das Dashboard bietet eine Reihe von Filtern, mit denen Sie die Abfragelast anzeigen können.
So öffnen Sie das Query Insights-Dashboard:
- Klicken Sie auf den Instanznamen, um die Übersichtsseite einer Instanz zu öffnen.
- Wählen Sie entweder im linken Navigationsbereich den Tab Query Insights aus oder klicken Sie den Link Zu „Query Insights“ für ausführliche Informationen über Abfragen und zur Leistung.
Das Dashboard "Query Insights" wird geöffnet. Es werden die folgenden Informationen zu Ihrer Instanz angezeigt:
![Zeigt das Query Insights-Dashboard mit Drop-down-Menüs für Datenbanken, Nutzer und Adressen an. Rechts neben den Drop-down-Menüs gibt es einen Filter zum Festlegen eines Zeitraums. Außerdem wird in einem Diagramm die Datenbanklast für Top-Abfragen angezeigt. Am unteren Rand des Diagramms befinden sich Auswahlfelder für die CPU-Kapazität, CPU und CPU-Wartezeit, E/A-Wartezeit und Wartezeit bei Sperrungen sowie ein Tab für Abfragen und Tags.](https://cloud.google.com/sql/images/query-insights-dashboard.png?hl=de)
- Datenbanken: Filtert die Abfragelast für eine bestimmte Datenbank oder für alle Datenbanken.
- Nutzer: Filtert die Abfragelast aus einem bestimmten Nutzerkonto.
- Clientadresse: Filtert die Abfragelast von einer bestimmten IP-Adresse.
- Zeitraum: Filtert die Abfragelast nach Zeiträumen, z. B. 1 Stunde, 6 Stunden, 1 Tag, 7 Tage, 30 Tage oder einen benutzerdefinierten Bereich.
- Diagrammladedatenbank: Zeigt das Abfrageladediagramm basierend auf den gefilterten Daten an.
- CPU-Kapazität, CPU- und CPU-Wartezeit, E/A-Wartezeit und Wartezeit für Sperrungen: Die Filter werden basierend auf den von Ihnen ausgewählten Optionen geladen. Weitere Informationen zu jedem dieser Filter finden Sie unter Datenbanklast für Top-Abfragen ansehen.
- Abfragen und Tags: Filtert die Abfragelast entweder nach einer ausgewählten Abfrage oder einem ausgewählten SQL-Abfrage-Tag. Siehe Datenbanklast filtern.
Datenbanklast für alle Abfragen ansehen
Die Anzahl der Datenbankabfragen ist ein Maß für die Arbeit (in CPU-Sekunden), die von den ausgeführten Abfragen in der ausgewählten Datenbank im Zeitverlauf ausgeführt wird. Bei jeder ausgeführten Abfrage wird entweder CPU-Ressourcen, E/A-Ressourcen oder Sperren von CPU-Ressourcen verwendet oder darauf gewartet. Die Datenbankabfragelast ist das Verhältnis der Zeit, die von allen innerhalb eines bestimmten Zeitfensters abgeschlossenen Abfragen benötigt wird, zur tatsächlich verstrichenen Zeit.
Das Dashboard „Query Insights“ der obersten Ebene zeigt das Diagramm Datenbanklast – alle Top-Abfragen. Mit Drop-down-Menüs im Dashboard können Sie das Diagramm für eine bestimmte Datenbank, einen bestimmten Nutzer oder eine bestimmte Kundenadresse filtern.
![Zeigt das Diagramm zur Datenbanklast mit einer Last für die CPU-Kapazität, die CPU und CPU-Wartezeit sowie die E/A-Wartezeit und Wartezeit nach Sperrung.](https://cloud.google.com/sql/images/database-load-graph.png?hl=de)
Die farbigen Linien in der Grafik zeigen die Abfragelast, in Kategorien unterteilt:
- CPU-Kapazität: Die Anzahl der CPUs, die auf der Instanz verfügbar sind.
- CPU und CPU-Wartezeit: Verhältnis der Zeit, die Abfragen in einem aktiven Zustand benötigen, zur tatsächlich verstrichenen Zeit. IO- und Sperrwartet blockieren keine Abfragen, die aktiv sind. Dieser Messwert kann bedeuten, dass die Abfrage entweder die CPU verwendet oder wartet, bis der Linux-Planer den Serverprozess plant, der die Abfrage ausführt, während andere Prozesse die CPU verwenden.
- IO-Wartezeit: Das Verhältnis der Zeit, die Abfragen auf E/A warten, zur tatsächlich verstrichenen Zeit. IO Wait beinhaltet Read IO Wait und Write IO Wait. Eine Aufschlüsselung der Informationen zu IO-Wartezeiten finden Sie in Cloud Monitoring. Weitere Informationen finden Sie unter Cloud SQL-Messwerte. Weitere Informationen finden Sie in der PostgreSQL-Ereignistabelle.
- Lock Wait: Das Verhältnis der Zeit, die Abfragen auf Sperren warten, zur tatsächlich verstrichenen Zeit. Dies beinhaltet Wartezeiten nach Sperrung, LwLock-Wartezeiten und BufferPin-Wartezeiten nach Sperrung. Verwenden Sie Cloud Monitoring, um eine Aufschlüsselung der Informationen für Sperrungswartezeiten anzuzeigen. Weitere Informationen finden Sie unter Cloud SQL-Messwerte.
Die farbigen Linien in der Grafik zeigen die Datenbanklast nach Ausführungszeit. Sehen Sie sich die Grafik an und verwenden Sie die Filteroptionen, um diese Fragen zu untersuchen:
- Ist die Abfragelast hoch? Ist eine Spitze oder ein Anstieg im Zeitverlauf zu sehen? Wenn keine hohe Last angezeigt wird, liegt das Problem nicht bei Ihrer Abfrage.
- Wie lange war die Last hoch? Ist sie erst jetzt hoch oder war sie schon lange hoch? Verwenden Sie die Bereichsauswahl, um verschiedene Zeiträume auszuwählen, um herauszufinden, wie lange das Problem besteht. Heranzoomen Sie, um ein Zeitfenster zu sehen, in dem Spitzen bei der Abfragelast beobachtet werden. Zoomen Sie heraus, um bis zu einer Woche der Zeitachse anzuzeigen.
- Wodurch wird die hohe Last verursacht? Sie können zur Auswahl der CPU-Kapazität, der CPU- und CPU-Wartezeit, der Wartezeit der Sperrung oder der E/A-Wartezeit wählen. Das Diagramm für jede dieser Optionen hat eine andere Farbe, sodass Sie leicht die Farbe mit der höchsten Last erkennen können. Die dunkelblaue Linie im Diagramm zeigt die maximale CPU-Kapazität des Systems an. Sie können die Abfragelast mit der maximalen CPU-Systemkapazität vergleichen. Anhand dieses Vergleichs können Sie erkennen, ob die CPU-Ressourcen einer Instanz erschöpft sind.
- Welche Datenbank hat die Auslastung? Wählen Sie im Drop-down-Menü „Datenbanken“ verschiedene Datenbanken aus, um die Datenbanken mit den höchsten Lasten zu finden.
- Verursachen bestimmte Nutzer oder IP-Adressen eine höhere Last? Wählen Sie in den Drop-down-Menüs verschiedene Nutzer und Adressen aus, um zu identifizieren, welche die höchste Last verursachen.
Datenbanklast filtern
Sie können die Datenbanklast nach Abfragen oder Tags filtern. Wenn Sie Query Insights für die Cloud SQL Enterprise Plus-Version verwenden, können Sie das Diagramm zur Datenbankauslastung anpassen, um die angezeigten Daten mithilfe einer der folgenden Dimensionen aufzuschlüsseln:- Alle Abfragen
Warteereignistypen
Warteereignisse
Datenbanken
Nutzer
Tags
Clientadressen
Wenn Sie das Diagramm zur Datenbanklast anpassen möchten, wählen Sie im Drop-down-Menü Datenbanklast nach Ausführungszeit eine Dimension aus.
Hauptursachen für die Datenbanklast ansehen
In der Tabelle Top-Dimensionen nach Datenbanklast sehen Sie die Hauptursachen für die Datenbanklast. In der Tabelle Top-Dimensionen nach Datenbanklast sehen Sie die Hauptfaktoren für den Zeitraum und die Dimension, die Sie im Drop-down-Menü des Diagramms Datenbanklast nach Ausführungszeit auswählen. Sie können den Zeitraum oder die Dimension ändern, um die wichtigsten Beitragenden für eine andere Dimension oder einen anderen Zeitraum zu sehen.
In der Tabelle Top-Dimensionen nach Datenlast können Sie die folgenden Tabs auswählen.
Tab | Beschreibung |
---|---|
Abfragen | Die Tabelle enthält die Top-normalisierten Abfragen nach Gesamtausführungszeit.
Für jede Abfrage werden die in den Spalten angezeigten Daten so aufgeführt:
|
Warteereignistypen | Die Tabelle enthält eine Liste der häufigsten Warteereignistypen, die im ausgewählten Zeitraum aufgetreten sind. Diese Tabelle ist nur für Abfragestatistiken für die Cloud SQL Enterprise Plus-Version verfügbar.
|
Warteereignisse | Die Tabelle enthält eine Liste der wichtigsten Warteereignisse, die im ausgewählten Zeitraum aufgetreten sind. Diese Tabelle ist nur für Abfragestatistiken für die Cloud SQL Enterprise Plus-Version verfügbar.
|
Datenbanken | Die Tabelle enthält eine Liste der Datenbanken, die im ausgewählten Zeitraum zur Auslastung beigetragen haben.
|
Nutzer | Die Tabelle enthält eine Liste der Top-Nutzer für den ausgewählten Zeitraum für alle ausgeführten Abfragen.
|
Tags | Weitere Informationen zu Tags finden Sie unter Nach Abfrage-Tags filtern. |
Clientadressen | Die Tabelle enthält eine Liste der Top-Nutzer für den ausgewählten Zeitraum für alle ausgeführten Abfragen.
|
Nach Abfragen filtern
Die Tabelle Abfragen bietet einen Überblick über die Abfragen, die die meisten Abfragelasten verursachen. Die Tabelle enthält alle normalisierten Abfragen für das Zeitfenster und die Optionen, die im Query Insights-Dashboard ausgewählt wurden. Es sortiert Abfragen nach der gesamten Ausführungszeit während des ausgewählten Zeitfensters.
![Zeigt das Diagramm für die Datenbanklast mit einer Last für Abfragen an, wobei die Filter für CPU-Kapazität, CPU und CPU-Wartezeit sowie E/A-Wartezeit und Wartezeit nach Sperrung ausgewählt sind.](https://cloud.google.com/sql/images/database-load-all-top-queries.png?hl=de)
Wählen Sie zum Sortieren der Tabelle eine Spaltenüberschrift oder ein Attribut aus Abfragen filtern aus. Die Tabelle enthält die folgenden Attribute:
- Abfrage: Der normalisierte Abfragestring. Query Insights zeigt standardmäßig nur 1.024 Zeichen im Abfragestring an.
Abfragen mit dem Label
UTILITY COMMAND
enthalten in der Regel die BefehleBEGIN
,COMMIT
undEXPLAIN
oder Wrapper-Befehle. - Datenbank: Die Datenbank, für die die Abfrage ausgeführt wurde.
- Last nach Gesamtzeit/Last nach CPU/Last nach E/A-Wartezeit/Last nach Wartezeit der Sperrung: Mit diesen Optionen können Sie bestimmte Abfragen filtern, um die größte Last zu ermitteln.
- % der Last nach Abfragen: Der prozentuale Anteil der Last nach einzelner Abfrage.
- Durchschnittliche Ausführungszeit (ms): Die durchschnittliche Zeit für die Ausführung der Abfrage.
- Aufrufe: Gibt an, wie oft die Anwendung die Abfrage aufgerufen hat.
- Durchschnittliche zurückgegebene Zeilen: Die durchschnittliche Anzahl der Zeilen, die für die Abfrage zurückgegeben wurden.
In Query Insights werden nur normalisierte Abfragen gespeichert und angezeigt.
Standardmäßig werden in Query Insights keine IP-Adressen oder Tag-Informationen erfasst. Sie können Query Insights aktivieren, um diese Informationen zu erfassen, und bei Bedarf die Erfassung deaktivieren.
Traces des Abfrageplans erfassen oder speichern keine konstanten Werte und entfernen keine personenidentifizierbaren Informationen, die die Konstante anzeigen kann.
Für PostgreSQL 9.6 und 10 zeigt Query Insights normalisierte Abfragen an, also ?
ersetzt den Wert der Literalkonstante. Im folgenden Beispiel wird die Namenskonstante entfernt und durch ?
ersetzt.
UPDATE "demo_customer" SET "customer_id" = ?::uuid, "name" = ?, "address" = ?, "rating" = ?, "balance" = ?, "current_city" = ?, "current_location" = ? WHERE "demo_customer"."id" = ?
Für PostgreSQL Version 11 und höher ersetzen $1
, $2
und ähnliche Variablen literalkonstante Werte.
UPDATE "demo_customer" SET "customer_id" = $1::uuid, "name" = $2, "address" = $3, "rating" = $4, "balance" = $5, "current_city" = $6, "current_location" = $7 WHERE "demo_customer"."id" = $8
Nach Abfrage-Tags filtern
Zur Behebung von Fehlern in Anwendungen müssen Sie zuerst Tags zu SQL-Abfragen hinzufügen. Abfragelasttags ermöglichen eine Aufschlüsselung der Abfragelast des ausgewählten Tags im Zeitverlauf.
Query Insights bietet anwendungsorientiertes Monitoring zur Diagnose von Leistungsproblemen für Anwendungen, die mit ORMs erstellt wurden. Wenn Sie für das gesamte Anwendungspaket verantwortlich sind, können Sie mit Query Insights Abfragen in einer Anwendungsansicht verfolgen. Mit der Tag-Kennzeichnung von Abfragen können Sie Probleme auf übergeordneten Konstrukten finden, z. B. mit der Geschäftslogik oder einem Mikrodienst.
Sie können Abfragen nach der Geschäftslogik taggen, z. B. mithilfe der Tags für Zahlungen, Inventar, Geschäftsanalysen oder Versand. Anschließend können Sie die Abfragelast ermitteln, die die verschiedenen Geschäftslogik erstellt haben. Dabei kann es sich beispielsweise um unerwartete Ereignisse wie Spitzen bei den Geschäftsanalyse-Tags um 13:00 Uhr oder unerwartetes Wachstum bei einem Trend zur Zahlungsbearbeitung in der letzten Woche handeln.
Zur Berechnung der Datenbanklast für Tag verwendet Query Insights die Zeit, die jede Abfrage mit dem von Ihnen ausgewählten Tag benötigt. Das Tool berechnet die Abschlusszeit an der Minutengrenze anhand der tatsächlich verstrichenen Zeit.
Wählen Sie im Dashboard „Query Insights“ die Option Tags aus, um die Tag-Tabelle aufzurufen. Die Tabelle sortiert Tags nach der Gesamtlast nach der Gesamtzeit.
![Zeigt das Query Insights-Dashboard mit der Last für Tags und einer Liste von Tags an.](https://cloud.google.com/sql/images/top-tags.png?hl=de)
Sie können die Tabelle sortieren. Wählen Sie dazu unter Tags filtern ein Attribut aus oder klicken Sie auf eine Spaltenüberschrift. Die Tabelle enthält die folgenden Attribute:
- Action, Controller, Framework, Route, Application, DB driver: Jedes Attribut, das Sie Ihren Abfragen hinzugefügt haben, wird als Spalte angezeigt. Sie müssen mindestens eine dieser Eigenschaften hinzufügen, wenn Sie nach Tags filtern möchten.
- Last nach Gesamtzeit/Last nach CPU/Last nach E/A-Wartezeit/Last nach Wartezeit der Sperrung: Optionen zum Filtern bestimmter Abfragen, um die größte Last für jede Option zu finden.
- Durchschnittliche Ausführungszeit (ms): Die durchschnittliche Zeit für die Ausführung der Abfrage.
- Durchschnittliche zurückgegebene Zeilen: Die durchschnittliche Anzahl der Zeilen, die für die Abfrage zurückgegeben wurden.
- Aufrufe: Gibt an, wie oft die Anwendung die Abfrage aufgerufen hat.
- Datenbank: Die Datenbank, für die die Abfrage ausgeführt wurde.
Bestimmte Abfrage oder bestimmtes Tag prüfen
Führen Sie auf dem Tab Abfragen oder Tags Folgendes aus, um festzustellen, ob eine Abfrage oder ein Tag die Ursache für das Problem ist:
- Wenn Sie die Liste in absteigender Reihenfolge sortieren möchten, klicken Sie auf den Header Last nach Gesamtzeit.
- Klicken Sie auf die Abfrage oder den Tag am Anfang der Liste. Sie hat die höchste Last und benötigt mehr Zeit als die anderen.
Es wird ein Dashboard mit den Details der ausgewählten Abfrage bzw. des ausgewählten Tags geöffnet.
Bestimmte Abfragelast prüfen
Das Dashboard für ein ausgewähltes Abfrage wird wie unten dargestellt angezeigt:
![Zeigt die Datenbanklast- und Latenzdiagramme für eine bestimmte Abfrage an.](https://cloud.google.com/sql/images/insights-query.png?hl=de)
Das Diagramm Datenbanklast – bestimmte Abfrage zeigt eine Messung der Arbeit (in CPU-Sekunden) an, die Ihre normalisierte Abfrage im Zeitverlauf in der ausgewählten Abfrage ausgeführt hat. Zur Berechnung der Last wird die von normalisierten Abfragen benötigte Zeit zur tatsächlich verstrichenen Zeit verwenden. Am Anfang der Tabelle werden die ersten 1.024 Zeichen der normalisierten Abfrage angezeigt. Literale werden dabei wegen Aggregation und personenidentifizierbaren Informationen entfernt.
![Zeigt das Diagramm zur Datenbanklast mit einer Last für eine bestimmte Abfrage mit ausgewählten Filtern für CPU-Kapazität, CPU und CPU-Wartezeit sowie E/A-Wartezeit und Wartezeit nach Sperrung.](https://cloud.google.com/sql/images/database-load-specific-query.png?hl=de)
Wie beim Diagramm zur Gesamtzeit der Abfragen können Sie die Last für eine bestimmte Abfrage nach Datenbank, Nutzer und Clientadresse filtern. Die Abfragelast wird in CPU-Kapazität, CPU und CPU-Wartezeit, E/A-Wartezeit und Wartezeit nach Sperrung aufgeteilt.
Bestimmte getaggte Abfragelast prüfen
Das Dashboard für ein ausgewähltes Tag wird wie unten dargestellt angezeigt. Beispiel: Wenn alle Abfragen aus einer Zahlung für Mikrodienste mit dem Tag payment
gekennzeichnet sind, können Sie mit dem Tag payment
den Umfang der Abfragelast anzeigen lassen, die im Trend liegt.
![Zeigt die Datenbanklast- und Latenzgrafiken auf der Seite für ein bestimmtes Tag an.](https://cloud.google.com/sql/images/per-tag.png?hl=de)
Das Diagramm Datenbanklast – bestimmte Tags zeigt eine Messung der Arbeit (in CPU-Sekunden) an, die Abfragen, die mit Ihren ausgewählten Tags übereinstimmen, in der ausgewählten Datenbank im Laufe der Zeit ausgeführt haben. Wie beim Diagramm zur Gesamtzeit der Abfragen können Sie die Last für eine bestimmte Abfrage nach Datenbank, Nutzer und Clientadresse filtern.
Vorgänge in einem Beispielabfrageplan prüfen
Mit einem Abfrageplan wird eine Stichprobe Ihrer Abfrage erstellt und in einzelne Vorgänge unterteilt. Die einzelnen Vorgänge in der Abfrage werden erläutert.
Das Diagramm Abfrageplanbeispiele zeigt alle Abfragepläne, die zu bestimmten Zeiten ausgeführt werden, sowie die Zeit, die jeder Plan benötigt hat. Sie können die Rate ändern, mit der die Stichproben von Abfrageplänen pro Minute erfasst werden. Siehe Abfragestatistiken aktivieren.
![Ein Diagramm für Beispielabfragepläne mit dem Ausführungszeitpunkt unten im Diagramm (x-Achse) und der Ausführungszeit in Sekunden rechts (y-Achse).](https://cloud.google.com/sql/images/query-samples.png?hl=de)
Standardmäßig zeigt das Feld rechts die Details für den Beispiel-Abfrageplan an, der die längste Zeit in Anspruch nimmt, wie im Diagramm Abfrageplan-Beispiele angezeigt. Klicken Sie auf den entsprechenden Kreis im Diagramm, um die Details für einen anderen Beispielabfrageplan anzuzeigen. Erweiterte Details zeigen ein Modell aller Vorgänge im Abfrageplan. Jeder Vorgang zeigt die Latenz, die zurückgegebenen Zeilen und die Kosten für diesen Vorgang an. Wenn Sie einen Vorgang auswählen, werden weitere Details wie freigegebene Trefferblöcke, Schematyp, Schleifen und Planzeilen angezeigt.
![Der Abfrageplan zeigt die Latenz und die Kosten für jeden Vorgang an, der für die Abfrage ausgeführt wird. Sie beginnt mit einer Aggregation, die 48 Zeilen mit einer Latenz von 31,06 ms und Kosten von 296,34 zurückgibt. Der nächste Vorgang ist eine verschachtelte Schleife, die in eine andere verschachtelte Schleife und ein Materialisieren aufgeteilt wird.
Die verschachtelte Schleife wird in eine andere verschachtelte Schleife und einen Indexscan aufgeteilt. Das Material führt zu einem Sequenzscan.](https://cloud.google.com/sql/images/query-plan-details.png?hl=de)
Versuchen Sie, das Problem anhand der folgenden Fragen einzugrenzen:
- Wie hoch ist der Ressourcenverbrauch?
- Wie hängt er mit anderen Abfragen zusammen?
- Ändert sich der Verbrauch im Laufe der Zeit?
Latenz prüfen
Latenz ist die tatsächlich verstrichene Zeit, die für den Abschluss der normalisierten Abfrage benötigt wird. Mit dem Diagramm Latenz können Sie die Latenz der Abfrage oder des Tags untersuchen. Im Latenz-Dashboard werden die Latenzen für das 50., 95. und 99. Perzentil angezeigt, um Ausreißerverhalten zu ermitteln.
Das folgende Bild zeigt das Diagramm für die Datenbanklast im 50. Perzentil für eine bestimmte Abfrage mit ausgewählten Filtern für CPU-Kapazität, CPU und CPU-Wartezeit sowie E/A-Wartezeit und Wartezeit nach Sperrung an.
![Zeigt das Diagramm zur Abfragelatenz für eine bestimmte Abfrage mit ausgewählten Filtern für CPU-Kapazität, CPU und CPU-Wartezeit sowie E/A-Wartezeit und Wartezeit nach Sperrung an.](https://cloud.google.com/sql/images/query-latency.png?hl=de)
Die Latenz der parallelen Abfragen wird in der tatsächlich verstrichenen Zeit gemessen, obwohl die Abfragelast für die Abfrage höher sein kann, da mehrere Kerne zum Ausführen bestimmter Teile der Abfrage verwendet werden.
Versuchen Sie, das Problem anhand der folgenden Fragen einzugrenzen:
- Wodurch wird die hohe Last verursacht? Wählen Sie Optionen aus, um die CPU-Kapazität, die CPU und CPU-Wartezeit sowie die E/A-Wartezeit und Wartezeit nach Sperrung zu sehen.
- Wie lange war die Last hoch? Ist sie nur jetzt hoch? Oder ist sie schon lange hoch? Ändern Sie den Zeitraum, um das Datum und die Uhrzeit zu ermitteln, zu der sich die Leistung der Last verschlechterte.
- Gibt es Latenzspitzen? Ändern Sie das Zeitfenster, um die bisherige Latenz für die normalisierte Abfrage zu untersuchen.
Verfolgen Sie die Ursache des Problems.
Wenn Sie die Bereiche und Zeiten finden, in denen die Last am höchsten war, identifizieren Sie die Ursache des Problems mithilfe von Tracing.
Um die genaue Ursache des Problems zu ermitteln, z. B. ein Modell, eine Ansicht, einen Controller, eine Route, einen Host oder einen Nutzer, bietet Query Insights eine kontextbezogene End-to-End-Anwendungs-Trace-Ansicht. Mit dieser Ansicht können Sie nachvollziehen, was bei einer bestimmten Anfrage auf Datenbankebene geschieht, und die Quelle einer problematischen Abfrage nach Modell, Ansicht, Controller und Route ermitteln.
Wenn Sie OpenCensus oder OpenTelemetry aktivieren, werden Informationen zu OpenCensus-Span sowie die Taginformationen innerhalb von SQL-Kommentaren an die Datenbank gesendet. Alle Traces von der Anwendung zu Cloud Logging sind mit Datenbankabfrageplan-Traces verknüpft, um dabei zu helfen, die Ursache des Problems zu ermitteln.
Klicken Sie im Bildschirm für die Beispielabfrage auf den Tab Ende zu Ende, um den Kontexttrace anzuzeigen.
![Wählen Sie ein End-to-End-Tag aus, um bestimmte Informationen über das Tag zu erhalten. Die Zusammenfassung zeigt die RPCs und die Gesamtdauer in ms für jeden Vorgang für dieses Tag an.](https://cloud.google.com/sql/images/end-to-end.png?hl=de)
Ermitteln Sie anhand der Tabellen Top-Clientadressen und der Top-Nutzer die höchsten Lasten, um herauszufinden, welcher Client und welcher Nutzer das Problem verursachen. Sie können dem Filter einen Nutzer oder eine IP-Adresse hinzufügen, um einen bestimmten Nutzer oder eine bestimmte Nutzer- oder Clientadresse genauer zu analysieren. Zu den Informationen in den Tabellen gehören der Prozentsatz der Abfragelast, die durchschnittliche Ausführungszeit in Millisekunden und die Anzahl der Aufrufe.
![Das Bild zeigt, dass die Last der Top-Clientadressen bei 100 %, die durchschnittliche Ausführungszeit bei 19.568 Sekunden und die Anzahl der Aufrufe bei 1.226 lag. Für Top-Nutzer verzeichneten die Postgres-Nutzer 100 % der Last, mit einer durchschnittlichen Ausführungszeit von 19.568 ms und einer Anzahl der Aufrufe von 1.226.](https://cloud.google.com/sql/images/top-client-addresses.png?hl=de)
Sie können Cloud Trace verwenden, um das End-to-End-Tracing für jeden Schritt im Abfrageplan zu sehen. Klicken Sie im Dashboard „Query Insights“ auf die Schaltfläche In Trace ansehen, um das Cloud Trace-Tool zu öffnen. Im Trace-Diagramm werden alle Traces angezeigt, die für den ausgewählten Zeitraum ausgeführt wurden.
![Das Trace-Diagramm zeigt alle Traces an, die für den ausgewählten Zeitraum ausgeführt wurden, in diesem Fall eine Stunde. Die Seite enthält auch eine Tabelle mit Latenz, HTTP-Methode, URL und dem Zeitpunkt, zu dem der Trace ausgeführt wurde.](https://cloud.google.com/sql/images/trace-list.png?hl=de)
Informationen finden Sie unter Traces suchen und ansehen.
Tags zu SQL-Abfragen hinzufügen
Das Taggen von SQL-Abfragen vereinfacht die Fehlerbehebung in Anwendungen. Sie können sqlcommenter verwenden, um Ihren SQL-Abfragen Tags entweder automatisch oder manuell hinzuzufügen.
sqlcommenter mit ORM verwenden
Wenn Sie ORM verwenden, anstatt SQL-Abfragen direkt zu schreiben, finden Sie möglicherweise keinen Anwendungscode, der Leistungsprobleme verursacht. Unter Umständen können Sie auch nicht analysieren, wie sich Ihr Anwendungscode auf die Abfrageleistung auswirkt. Query Insights bietet eine Open-Source-Bibliothek namens sqlcommenter, um dieses Problem zu beheben. Diese Bibliothek ist für Entwickler und Administratoren nützlich, die ORM-Tools verwenden, um zu erkennen, welcher Anwendungscode Leistungsprobleme verursacht.
Wenn Sie ORM und sqlcommenter zusammen verwenden, werden die Tags automatisch erstellt. Sie müssen in der Anwendung weder Code hinzufügen noch ändern.
Sie können sqlcommenter auf dem Anwendungsserver installieren. Die Instrumentierungsbibliothek ermöglicht die Weitergabe von Anwendungsinformationen in Verbindung mit Ihrem Modell, Ihrer Ansicht und Ihrem MVC-Framework zusammen mit den Abfragen als SQL-Kommentar. Die Datenbank ruft diese Tags ab und beginnt die Aufzeichnung und Aggregation von Statistiken nach Tags. Dies sind orthogonale Statistiken mit normalisierten Abfragen. Query Insights zeigt die Tags an, damit Sie wissen, welche Anwendung die Abfragelast verursacht, und den Anwendungscode finden können, der die Leistungsprobleme verursacht.
Ergebnisse in SQL-Datenbanklogs werden so angezeigt:
SELECT * from USERS /action='run+this', controller='foo%3', traceparent='00-01', tracestate='rojo%2'/
Zu den unterstützten Tags gehören der Controllername, die Route, das Framework und die Aktion.
Die Gruppe von ORM-Tools in sqlcommenter wird für die folgenden Programmiersprachen unterstützt:
Python |
|
Java |
|
Ruby |
|
Node.js |
|
Weitere Informationen über sqlcommenter und wie Sie es in Ihrem ORM-Framework verwenden, finden Sie in der sqlcommenter-Dokumentation.
Tags mit sqlcommenter hinzufügen
Wenn Sie ORM nicht verwenden, müssen Sie sqlcommenter-Tags oder Kommentare manuell im richtigen SQL-Kommentarformat zu Ihrer SQL-Abfrage hinzufügen. Außerdem müssen Sie jede SQL-Anweisung mit einem Kommentar erweitern, der ein serialisiertes Schlüssel/Wert-Paar enthält. Verwenden Sie mindestens einen der folgenden Schlüssel:
action=''
controller=''
framework=''
route=''
application=''
db driver=''
Query Insights löst alle anderen Schlüssel ab.
Query Insights deaktivieren
So deaktivieren Sie Query Insights für eine Cloud SQL-Instanz mithilfe der Google Cloud Console:
-
Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.
- Klicken Sie auf den Instanznamen, um die Übersichtsseite einer Instanz zu öffnen.
- Klicken Sie in der Kachel Konfiguration auf Konfiguration bearbeiten.
- Erweitern Sie im Abschnitt Konfigurationsoptionen die Option Query Insights.
- Entfernen Sie das Häkchen aus dem Kästchen Query Insights aktivieren.
- Klicken Sie auf Speichern.
Um Query Insights für eine Cloud SQL-Instanz mithilfe von gcloud
zu deaktivieren, führen Sie gcloud sql instances patch
mit dem Flag --no-insights-config-query-insights-enabled
so aus, nachdem Sie INSTANCE_ID durch die ID der Instanz ersetzt haben.
gcloud sql instances patchINSTANCE_ID
--no-insights-config-query-insights-enabled
Rufen Sie die Methode instances.patch
auf, wobei queryInsightsEnabled
so auf false
gesetzt ist, um Query Insights für eine Cloud SQL-Instanz mithilfe der REST API zu deaktivieren.
Ersetzen Sie diese Werte in den folgenden Anfragedaten:
- project-id: die Projekt-ID
- instance-id: Die Instanz-ID.
HTTP-Methode und URL:
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id /instances/instance-id
JSON-Text anfordern:
{ "settings" : { "insightsConfig" : { "queryInsightsEnabled" : false } } }
Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:
curl (Linux, macOS oder Cloud Shell)
Speichern Sie den Anfragetext in einer Datei mit dem Namen request.json
und führen Sie den folgenden Befehl aus:
curl -X PATCH \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json; charset=utf-8" \
-d @request.json \
"https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id /instances/instance-id "
PowerShell (Windows)
Speichern Sie den Anfragetext in einer Datei mit dem Namen request.json
und führen Sie den folgenden Befehl aus:
$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }
Invoke-WebRequest `
-Method PATCH `
-Headers $headers `
-ContentType: "application/json; charset=utf-8" `
-InFile request.json `
-Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id /instances/instance-id " | Select-Object -Expand Content
Sie sollten eine JSON-Antwort ähnlich wie diese erhalten:
{ "kind": "sql#operation", "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id /instances/instance-id ", "status": "PENDING", "user": "user@example.com", "insertTime": "2021-01-28T22:43:40.009Z", "operationType": "UPDATE", "name": "operation-id ", "targetId": "instance-id ", "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id /operations/operation-id ", "targetProject": "project-id " }
Abfragestatistiken für Cloud SQL Enterprise Plus deaktivieren
So deaktivieren Sie Query Insights für die Cloud SQL Enterprise Plus-Version:
-
Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.
- Klicken Sie auf den Instanznamen, um die Übersichtsseite einer Instanz zu öffnen.
- Klicken Sie auf Bearbeiten.
- Maximieren Sie im Bereich Instanz anpassen den Eintrag Abfragestatistiken.
- Entfernen Sie das Häkchen aus dem Kästchen Enterprise Plus-Funktionen aktivieren.
- Klicken Sie auf Speichern.
Nächste Schritte
- Blog zur Einführung: Datenbank-Sichtbarkeit für Entwickler: Einführung von Cloud SQL Insights
- Siehe Cloud SQL-Messwerte.
Die Messwerttyp-Strings von Query Insights beginnen mit
database/postgresql/insights
. - Blog: Mit Cloud SQL Insights die Fähigkeiten zur Fehlerbehebung bei Abfragen verbessern
- Video: Einführung in Cloud SQL Insights
- Podcast: Cloud SQL Insights
- Informationen zu Codelabs
- Blog: Einführung von Sqlcommenter: Eine Open-Source-Bibliothek mit ORM-Instrumentierung
- Blog: Abfrage-Tagging mit Sqlcommenter aktivieren