Abfragestatistiken verwenden, um die Abfrageleistung zu verbessern

MySQL | PostgreSQL | SQL Server

Auf dieser Seite wird beschrieben, wie Sie mit dem Query Insights-Dashboard Leistungsprobleme erkennen und analysieren.

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:

Query Insights wird für alle Cloud SQL-Maschinentypen unterstützt und ist in allen Google Cloud-Regionen verfügbar.

Preise

Für Query Insights fallen keine zusätzlichen Kosten an. Im Query Insights-Dashboard haben Sie Zugriff auf die Daten einer Woche.

Query Insights 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.

Hinweis

Sie benötigen bestimmte IAM-Berechtigungen, um einen Abfrageplan aufzurufen oder End-to-End-Tracing durchzuführen. Erstellen Sie eine benutzerdefinierte Rolle und fügen Sie ihr die IAM-Berechtigung cloudtrace.traces.get hinzu. Fügen Sie diese Rolle dann jedem Nutzerkonto hinzu, das Query Insights verwenden muss.

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 Ihr Google 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:
Zu "APIs und Dienste"
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.

Abfragestatistiken aktivieren

Query Insights-Messwerte werden im inaktiven Zustand verschlüsselt. Nutzer mit Zugriff auf das Cloud SQL-Dashboard können im Query Insights-Dashboard auf Query Insights-Messwerte zugreifen. Wenn Sie berechtigt sind, Instanzen zu aktualisieren, können Sie Query Insights konfigurieren. 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.

Console

Abfragestatistiken für eine Instanz aktivieren

Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.

Cloud SQL-Instanzen aufrufen
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.
Klicken Sie das Kästchen Query Insights aktivieren an.
Optional: Wählen Sie eine oder mehrere der folgenden Query Insights-Optionen aus:

Client-IP-Adressen speichern

Standardwert: false

Speichert die Client-IP-Adressen, von denen Abfragen stammen, und gruppiert diese Daten, 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.
Klicken Sie auf Speichern.

Query Insights für mehrere Instanzen aktivieren

Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.

Cloud SQL-Instanzen aufrufen
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.
Hinweis: Mit diesem Schritt wird Query Insights für Ihre Instanzen basierend auf der Standardkonfiguration aktiviert.

gcloud

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 folgendermaßen aus, nachdem Sie INSTANCE_ID durch die ID der Instanz ersetzt haben.

gcloud sql instances patch INSTANCE_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 gruppiert diese Daten, 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.

Dabei gilt:

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 patch INSTANCE_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

REST Version 1

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)

Hinweis: Der folgende Befehl setzt voraus, dass Sie sich mit Ihrem Nutzerkonto in der gcloud CLI angemeldet haben. Dazu haben Sie gcloud init oder gcloud auth login ausgeführt oder die Cloud Shell genutzt, die Sie automatisch in der gcloud CLI anmeldet. Um herauszufinden, welches Konto gerade aktiv ist, führen Sie gcloud auth list aus.

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"
}

Terraform

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 ist 1024 und Sie können ihn auf einen Wert zwischen 256 und 4500 in Byte konfigurieren.

record_application_tags: Setzen Sie den Wert auf true, wenn Sie Anwendungs-Tags aus der Abfrage aufzeichnen möchten.

record_client_address: Setzen Sie den Wert auf true, wenn Sie die Client-IP-Adresse aufzeichnen möchten.

query_plans_per_minute: Der Standardwert ist 5 und Sie können ihn auf einen Wert zwischen 5 und 20 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 als main.tf bezeichnet.
```
mkdir DIRECTORY && cd DIRECTORY && 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.

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.

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. Stunde, Tag, Woche, Monat 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 eine Messung der 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.

Die farbigen Linien in der Grafik zeigen die Abfragelast, in vier 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.

Hinweis: CPU-Lasten berücksichtigen sowohl die Laufzeit als auch die Zeit, die auf den Linux-Planer gewartet wird, um den laufenden Serverprozess zu planen. Daher kann die CPU-Auslastung die maximale Kernlinie überschreiten.
E/A-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.

Weitere Informationen finden Sie in der PostgreSQL-Ereignistabelle.

Eine Gliederung der Informationen zu IO Waits nach Sperrung können Sie in Cloud Monitoring anzeigen. Weitere Informationen finden Sie unter Cloud SQL-Messwerte.
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.

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. Vergrößern Sie die Ansicht, 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.

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.

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 Befehle BEGIN, COMMIT und EXPLAIN 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: Die Optionen, mit denen Sie bestimmte Abfragen filtern können, um die größte Last zu ermitteln.
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 erfasst Query Insights keine IP-Adressen oder Tag-Informationen. 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, usw. 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 abnormales 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 anzuzeigen. 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.

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.

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.

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.

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).

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.

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.

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.

Damit Sie die Ursache des Problems (z.B. ein Modell, eine Ansicht, einen Controller, eine Route, einen Host oder einen Nutzer) ermitteln können, bietet Query Insights eine kontextbezogene End-to-End-Ansicht zur Anwendungsverfolgung. Diese Ansicht bietet Informationen zu den Vorgängen auf Datenbankebene für eine bestimmte Anfrage und zum Ermitteln der Ursache einer problematischen Abfrage nach Modell, Ansicht, Controller und Route.

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.

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.

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.

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	Django psycopg2 Sqlalchemy Flask
Java	Hibernate Frühling
Ruby	Rails
Node.js	Knex.js Sequelize.js Express.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

Console

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.

Cloud SQL-Instanzen aufrufen
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.

gcloud

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 patch INSTANCE_ID \
--no-insights-config-query-insights-enabled

REST

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 in etwa folgende JSON-Antwort 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"
}

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.