Abfrageleistung mit Query Insights verbessern

Vorschau

Dieses Produkt unterliegt den Bedingungen des Pre-GA-Angebots in den Google Cloud Nutzungsbedingungen. Für Pre-GA-Produkte ist eventuell nur eingeschränkter Support verfügbar. Änderungen an diesen Produkten sind möglicherweise nicht mit anderen Pre-GA-Versionen kompatibel. Weitere Informationen finden Sie unter Beschreibungen der Startphase.

Auf dieser Seite wird beschrieben, wie Sie mit dem Query Insights-Dashboard Leistungsprobleme erkennen und analysieren. Eine Übersicht über diese Funktion finden Sie unter Query Insights.

Sie können die Unterstützung von Gemini in Datenbanken verwenden, um Ihre AlloyDB-Ressourcen zu überwachen und Fehler zu beheben. Weitere Informationen finden Sie unter Mit Gemini in Datenbanken beobachten und Fehler beheben.

Hinweise

Wenn Sie oder andere Nutzer den Abfrageplan sehen oder ein End-to-End-Tracing benötigen, brauchen Sie bestimmte IAM-Berechtigungen (Identity and Access Management). Sie können eine benutzerdefinierte Rolle erstellen und ihr die erforderlichen IAM-Berechtigungen hinzufügen. Sie können diese Rolle dann jedem Nutzerkonto hinzufügen, das Query Insights zur Behebung von Problemen verwendet. Weitere Informationen finden Sie im Hilfeartikel Benutzerdefinierte Rollen erstellen

Die benutzerdefinierte Rolle muss die folgende IAM-Berechtigung haben: cloudtrace.traces.get.

Query Insights-Dashboard öffnen

So öffnen Sie das Query Insights-Dashboard:

1. Klicken Sie in der Liste der Cluster und Instanzen auf eine Instanz.
2. Klicken Sie auf der Seite „Clusterübersicht“ unter der Messwertgrafik auf Zu „Query Insights“ für ausführliche Informationen über Abfragen und zur Leistung oder wählen Sie im linken Navigationsbereich den Tab Query Insights aus.

Auf der nächsten Seite können Sie die Ergebnisse mithilfe der folgenden Optionen filtern:

1. Instanzauswahl Hier können Sie entweder die primäre Instanz oder Lesepoolinstanzen im Cluster auswählen. Standardmäßig ist die primäre Instanz ausgewählt. Die angezeigten Details werden für alle verbundenen Lesepoolinstanzen und ihre Knoten aggregiert.
2. Datenbank. Filtert die Abfragelast für eine bestimmte Datenbank oder für alle Datenbanken.
3. Nutzer. Mit diesem Filter wird die Abfragelast aus bestimmten Nutzerkonten gefiltert.
4. Client-Adresse Filtert die Abfragelast von einer bestimmten IP-Adresse.
5. Zeitraum. Filtert die Abfragelast nach Zeiträumen (z. B. Stunde, Tag, Woche oder benutzerdefinierter Bereich).

Hinweis: Wenn Sie Gemini in Datenbanken aktivieren, beträgt die Datenaufbewahrungsrichtlinie für Abfragemesswerte 30 Tage.

Konfiguration für Abfragestatistiken bearbeiten

Query Insights ist standardmäßig in AlloyDB-Instanzen aktiviert. Sie können die Standardkonfiguration für Query Insights bearbeiten.

So bearbeiten Sie die Query Insights-Konfiguration für eine AlloyDB-Instanz:

Console

1. Rufen Sie in der Google Cloud Console die Seite Cluster auf.

   Zu den Clustern

2. Klicken Sie in der Spalte Ressourcenname auf einen Cluster.

3. Klicken Sie im linken Navigationsbereich auf Statistiken zu Abfragen.

4. Wählen Sie in der Liste Abfragestatistiken die Option Primär oder Lesepool aus und klicken Sie dann auf Bearbeiten.

5. Bearbeiten Sie die Felder Query Insights:

   1. Wenn Sie das Standardlimit von 1.024 Byte für die Abfragelänge ändern möchten, die von AlloyDB analysiert werden soll, geben Sie in das Feld Abfragelänge anpassen eine Zahl zwischen 256 und 4.500 ein.

      Die Instanz wird neu gestartet, nachdem Sie dieses Feld bearbeitet haben.

      Hinweis: Höhere Limits für die Abfragelänge erfordern mehr Arbeitsspeicher.

   2. Sie können die Funktionen von Query Insights an Ihre Anforderungen anpassen. Dazu stehen Ihnen die folgenden Optionen zur Verfügung:

      • Abfragepläne aktivieren: Wenn Sie dieses Kästchen anklicken, sehen Sie die Vorgänge, die zum Ausführen einer Abfragestichprobe verwendet werden.
        Geben Sie im Feld Maximale Abtastrate eine Zahl zwischen 1 und 20 ein. Standardmäßig ist die Abtastrate auf 5 festgelegt. Wenn Sie die Stichprobenerhebung deaktivieren möchten, entfernen Sie das Häkchen aus dem Kästchen Abfragepläne aktivieren.
        Die Abtastrate bestimmt die maximale Anzahl von Abfragen, die AlloyDB pro Minute für die Instanz pro Knoten erfassen kann.
      • Client-IP-Adressen speichern Wenn Sie dieses Kästchen anklicken, können Sie die Herkunft Ihrer Abfragen ermitteln und diese Informationen gruppieren, um Messwerte zu erstellen.
      • Anwendungs-Tags speichern Wenn Sie dieses Kästchen anklicken, sehen Sie, welche getaggten Anwendungen Anfragen stellen, und können diese Informationen gruppieren, um Messwerte zu erstellen. Weitere Informationen zu Anwendungs-Tags finden Sie in der Spezifikation.

6. Klicken Sie auf Instanz aktualisieren.

gcloud

So aktivieren Sie Query Insights für eine AlloyDB-Instanz mithilfe von Google Cloud CLI-Befehlen:

1. Installieren Sie die Google Cloud CLI.
2. Führen Sie folgenden Befehl aus, um die gcloud CLI zu initialisieren:

   gcloud init
   

3. Wenn Sie eine lokale Shell verwenden, erstellen Sie lokale Anmeldedaten zur Authentifizierung für Ihr Nutzerkonto:

   gcloud auth application-default login
   

   Wenn Sie Cloud Shell verwenden, ist das nicht erforderlich.

   Weitere Informationen finden Sie unter Authentifizierung für eine lokale Entwicklungsumgebung einrichten.

Beispiel:

gcloud alloydb instances update INSTANCE \
--cluster=CLUSTER \
--project=PROJECT \
--region=REGION \
--insights-config-query-string-length=QUERY_LENGTH \
--insights-config-query-plans-per-minute=QUERY_PLANS \
--insights-config-record-application-tags \
--insights-config-record-client-address

Ersetzen Sie Folgendes:

• <var>CLUSTER</var>: die ID der zu aktualisierenden Instanz
• <var>CLUSTER</var>: die ID des Clusters der Instanz
• <var>PROJECT</var>: die ID des Projekts des Clusters
• <var>REGION</var>: Die Region des Clusters, z. B. us-central1
• <var>QUERY_LENGTH</var>: die Länge der Abfrage, die zwischen 256 und 4.500 liegt
• <var>QUERY_PLANS</var>: die Anzahl der Abfragepläne, die pro Minute konfiguriert werden sollen

Verwenden Sie außerdem eines oder mehrere der folgenden optionalen Flags:

• --insights-config-query-string-length: Legt die maximale Länge der Abfrage 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. Wenn Sie die Abfragelänge ändern möchten, müssen Sie die Instanz neu starten. Sie können weiterhin Tags zu Abfragen hinzufügen, die die Längenbegrenzung überschreiten.
• --insights-config-query-plans-per-minute: Standardmäßig werden in allen Datenbanken der Instanz maximal fünf ausgeführte Abfrageplanstichproben pro Minute erfasst. Ändern Sie diesen Wert in eine Zahl von 1 bis 20. Wenn Sie die Stichprobenerhebung deaktivieren möchten, geben Sie „0“ ein. Wenn Sie die Abtastrate erhöhen, erhalten Sie wahrscheinlich mehr Datenpunkte. Allerdings kann dies zu Leistungseinbußen führen.
• --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. Wenn Sie keine Client-IP-Adressen speichern möchten, verwenden Sie --no-insights-config-record-client-address.
• --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. Wenn Sie keine Anwendungs-Tags speichern möchten, verwenden Sie --no-insights-config-record-application-tags.

Terraform

Wenn Sie Query Insights mit Terraform konfigurieren möchten, verwenden Sie die Ressource google_alloydb_instance.

Beispiel:

  query_insights_config {
    query_string_length = QUERY_STRING_LENGTH_VALUE
    record_application_tags = RECORD_APPLICATION_TAG_VALUE
    record_client_address = RECORD_CLIENT_ADDRESS_VALUE
    query_plans_per_minute = QUERY_PLANS_PER_MINUTE_VALUE5
  }
  

Ersetzen Sie Folgendes:

• QUERY_STRING_LENGTH_VALUE: Länge des Abfragestrings. Der Standardwert ist 1024. Jede Ganzzahl zwischen 256 und 4.500 ist gültig.
• RECORD_APPLICATION_TAG_VALUE: Anwendungs-Tag für eine Instanz aufzeichnen. Der Standardwert ist true.
• RECORD_CLIENT_ADDRESS_VALUE: Clientadresse für eine Instanz aufzeichnen. Der Standardwert ist true.

• QUERY_PLANS_PER_MINUTE_VALUE: Die Anzahl der Abfrageausführungspläne, die von Insights pro Minute für alle Abfragen erfasst werden. Der Standardwert ist 5. Jede Ganzzahl zwischen 0 und 20 ist zulässig.

  Informationen zum Anwenden oder Entfernen einer Terraform-Konfiguration finden Sie unter Grundlegende Terraform-Befehle.

  Die Beispielkonfiguration der Instanz mit der hinzugefügten Konfiguration für Suchstatistiken sollte so aussehen:

  resource "google_alloydb_instance" "instance_name" {
  provider = "google-beta"
  cluster       = google_alloydb_cluster.default.name
  instance_id   = "instance_id"
  instance_type = "PRIMARY"
  
  machine_config {
   cpu_count = 8
  }
  
  query_insights_config {
  query_string_length = 1024
  record_application_tags = false
  record_client_address = false
  query_plans_per_minute = 5
  }
  
  depends_on = [google_alloydb_instance.default]
  }
  

REST Version 1

In diesem Beispiel werden die Einstellungen für die Observability in Ihrer AlloyDB-Instanz konfiguriert. Eine vollständige Liste der Parameter für diesen Aufruf finden Sie unter Methode: projects.locations.clusters.instances.patch.

Um die Einstellungen für Query Insights zu konfigurieren, ändern Sie die optionalen Felder nach Bedarf. Eine vollständige Liste der Felder für diesen Aufruf finden Sie unter QueryInsightsInstanceConfig.

Ersetzen Sie diese Werte in den folgenden Anweisungen:

• CLUSTER_ID: die ID des von Ihnen erstellten Clusters. Sie muss mit einem Kleinbuchstaben beginnen und darf Kleinbuchstaben, Ziffern und Bindestriche enthalten.
• PROJECT_ID: die ID des Projekts, in dem der Cluster platziert werden soll.
• LOCATION_ID: die ID der Region des Clusters.
• INSTANCE_ID: Name der primären Instanz, die Sie erstellen möchten.

Verwenden Sie die folgende PATCH-Anfrage, um die Instanzkonfiguration zu ändern:

PATCH https://alloydb.googleapis.com/v1beta/{instance.name=projects/PROJECT_ID/locations/LOCATION_ID/clusters/CLUSTER_ID/instances/INSTANCE_ID?updateMask=observabilityConfig.enabled}

Der JSON-Anfragetext, in dem alle Observabilitätsfelder konfiguriert werden, sieht so aus:

{
  "queryStringLength": integer,
  "recordApplicationTags": boolean,
  "recordClientAddress": boolean,
  "queryPlansPerMinute": integer
}

Schritte zur Verbesserung der Abfrageleistung

Query Insights behebt Fehler in AlloyDB-Abfragen, um Leistungsprobleme zu erkennen. 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.

Mit dem Tool "Query Insights" können Sie Probleme mit der Abfrageleistung erkennen und analysieren. Mit Query Insights können Sie Fehler in Abfragen in vier Schritten beheben:

1. Datenbanklast für alle Abfragen ansehen
2. Potenziell problematische Abfrage oder potenziell problematisches Tag identifizieren
3. Abfrage oder Tag ansehen, um Probleme zu ermitteln
4. Verfolgen Sie die Ursache des Problems.

Datenbanklast für alle Abfragen ansehen

Das Dashboard „Query Insights“ der obersten Ebene zeigt das Diagramm Datenbanklast – alle Top-Abfragen mit gefilterten Daten. 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.

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.

• IO Wait: Das Verhältnis der Zeit, die Abfragen auf IO 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 Messwertdiagramme.

• 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. Eine Gliederung der Informationen zu Wartezeiten nach Sperrung können Sie in Cloud Monitoring anzeigen. Weitere Informationen finden Sie unter Messwertdiagramme.

Sehen Sie sich nun das Diagramm an und beantworten Sie die folgenden Fragen mithilfe der Filteroptionen:

1. 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 Ihren Abfragen.
2. Wie lange war die Last hoch? Ist sie nur jetzt hoch? Oder ist sie schon lange hoch? Verwenden Sie die Bereichsauswahl, um verschiedene Zeiträume auszuwählen, um zu ermitteln, wie lange das Problem aufgetreten ist. Sie können auch heranzoomen, um ein Zeitfenster anzuzeigen, in dem die Spitzen der Abfragelasten beobachtet werden. Sie können herauszoomen, um bis zu einer Woche auf der Zeitachse zu sehen.
3. Wodurch wird die hohe Last verursacht? Sie können zur Auswahl der CPU-Kapazität, der CPU- und CPU-Wartezeit, der Schloss-Wartezeit oder der E/A-Wartezeit wählen. Die Grafik für diese Optionen hat eine andere Farbe, sodass Sie sehen können, welche die höchste Auslastung aufweist. 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 feststellen, ob die CPU-Ressourcen einer Instanz erschöpft sind.
4. 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.
5. Verursachen bestimmte Nutzer oder IP-Adressen höhere Lasten? Wählen Sie in den Drop-down-Menüs verschiedene Nutzer und Adressen aus, um zu vergleichen, welche die höchste Last verursachen.

Datenbanklast filtern

Im Bereich Abfragen und Tags können Sie die Abfragelast nach einer ausgewählten Abfrage oder einem SQL-Abfrage-Tag filtern oder sortieren.

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.

Standardmäßig werden Abfragen in der Tabelle nach der Gesamtausführungszeit innerhalb des ausgewählten Zeitraums sortiert.

Wählen Sie zum Filtern der Tabelle ein Attribut aus Filterabfragen aus. Wählen Sie zum Sortieren der Tabelle eine Spaltenüberschrift aus. Die Tabelle enthält die folgenden Attribute:

• Abfragestring. Der normalisierte Abfragestring. Query Insights zeigt standardmäßig nur 1024 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 Sperre. Mit diesen Optionen können Sie bestimmte Abfragen filtern, um die höchste Last für jede Option zu ermitteln.

• Durchschnittliche Ausführungszeit (ms). Die Gesamtzeit, die alle Teilaufgaben in allen parallelen Workern für die Ausführung der Abfrage benötigen. Weitere Informationen finden Sie unter Durchschnittliche Ausführungszeit und Dauer.

• Anzahl an Aufrufen. Die Häufigkeit, mit der die Abfrage von der Anwendung aufgerufen wurde.

• Durchschn. abgerufene Zeilen. Die durchschnittliche Anzahl der für die Abfrage abgerufenen Zeilen.

Query Insights zeigt normalisierte Abfragen an, also werden die Werte der Literalkonstanten durch $1, $2 usw. ersetzt. Beispiel:

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

Der Wert der Konstante wird ignoriert, damit in Query Insights ähnliche Abfragen aggregiert und personenidentifizierbare Informationen entfernt werden können, die die Konstante möglicherweise anzeigt.

Nach Abfrage-Tags filtern

Zur Behebung von Fehlern in Anwendungen müssen Sie zuerst Tags zu SQL-Abfragen hinzufügen.

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 höherer Ebene ermitteln, z. B. mit der Geschäftslogik, einem Mikrodienst oder einem anderen Konstrukt. 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 Arten von Geschäftslogik erstellt haben. Beispielsweise kann es zu unerwarteten Ereignissen kommen, z. B. zu Spitzenspitzen für ein Business Analytics-Tag um 13:00 Uhr. Oder es kann zu einem unerwarteten Wachstum für einen Zahlungsdienst in der vergangenen Woche kommen.

Abfragelasttags ermöglichen eine Aufschlüsselung der Abfragelast des ausgewählten Tags im Zeitverlauf.

Zur Berechnung der Datenbanklast für Tag verwendet Query Insights die Zeit, die jede Abfrage mit dem von Ihnen ausgewählten Tag benötigt. Query Insights berechnet die benötigte Zeit anhand der tatsächlich verstrichenen Zeit.

Wählen Sie im Dashboard "Query Insights" die Option TAGS aus, um die Tag-Tabelle aufzurufen. Die Tabelle TAGS sortiert Tags nach der Gesamtlast nach der Gesamtzeit.

Sie können die Tabelle sortieren, indem Sie unter Filterabfragen ein Attribut auswählen oder auf eine Spaltenüberschrift klicken. 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 Sperre. Mit diesen Optionen können Sie bestimmte Abfragen filtern, um die höchste Last für jede Option zu ermitteln.
• Durchschnittliche Ausführungszeit (ms). Die Gesamtzeit, die alle Teilaufgaben in allen parallelen Workern für die Ausführung der Abfrage benötigen. Weitere Informationen finden Sie unter Durchschnittliche Ausführungszeit und Dauer.
• Anzahl an Aufrufen. Die Häufigkeit, mit der die Abfrage von der Anwendung aufgerufen wurde.
• Durchschn. abgerufene Zeilen. Die durchschnittliche Anzahl der für die Abfrage abgerufenen Zeilen.
• 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 die Ursache des Problemszu ermitteln:

1. Klicken Sie auf den Header Last nach Gesamtzeit, um die Liste in absteigender Reihenfolge zu sortieren.
2. Klicken Sie auf die Abfrage oder das Tag, das vermeintlich die höchste Last hat und mehr Zeit als die anderen benötigt.

Es wird ein Dashboard mit den Details der ausgewählten Abfrage bzw. des ausgewählten Tags geöffnet.

Wenn Sie eine Abfrage ausgewählt haben, wird eine Übersicht über die ausgewählte Abfrage angezeigt:

Wenn Sie ein Tag ausgewählt haben, wird eine Übersicht über das ausgewählte Tag angezeigt.

Last für eine bestimmte Abfrage oder ein bestimmtes Tag prüfen

Das Diagramm Datenbanklast – bestimmte Abfrage zeigt eine Messung der Arbeit (in CPU-Sekunden) an, die Ihre ausgewählte 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. 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.

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.

Latenz prüfen

Mit dem Diagramm Latenz können Sie die Latenz der Abfrage oder des Tags untersuchen. Latenz ist die tatsächlich verstrichene Zeit, die für den Abschluss der normalisierten Abfrage benötigt wird. Im Latenz-Dashboard werden die Latenzen für das 50., 95. und 99. Perzentil angezeigt, um Ausreißerverhalten zu ermitteln.

Die Latenz der parallelen Abfragen wird in der tatsächlich verstrichenen Zeit gemessen, obwohl die Datenbanklast für die Abfrage höher sein kann, da mehrere Kerne zum Ausführen bestimmter Teile der Abfrage verwendet werden.

Versuchen Sie, das Problem folgendermaßen einzugrenzen:

1. 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.
2. Wie lange war die Last hoch? Ist sie nur jetzt hoch? Oder ist sie schon lange hoch? Ändern Sie die Zeiträume, um das Datum und die Uhrzeit zu ermitteln, zu der sich die Leistung der Last verschlechterte.
3. Gibt es Latenzspitzen? Sie können das Zeitfenster ändern, um die bisherige Latenz für die normalisierte Abfrage zu untersuchen.

Wenn Sie die Bereiche und Zeiten für die höchste Last ermittelt haben, können Sie die Informationen weiter aufschlüsseln.

Latenz im gesamten Cluster prüfen

Mit dem Diagramm P99-Latenz für dieselbe Abfrage im gesamten Cluster können Sie die P99-Latenz der Abfrage oder des Tags auf verschiedenen Instanzen im Cluster untersuchen.

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.

Um Details für den Beispielabfrageplan anzuzeigen, klicken Sie auf die Punkte im Diagramm Beispielabfragepläne. Die meisten ausgeführten Abfragepläne werden angezeigt, allerdings nicht alle. 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, sehen Sie weitere Details wie gemeinsame Treffer, den Typ des Schemas, die tatsächlichen Schleifen, die Planzeilen und vieles mehr.

Versuchen Sie, das Problem anhand der folgenden Fragen einzugrenzen:

1. Wie hoch ist der Ressourcenverbrauch?
2. Wie hängt er mit anderen Abfragen zusammen?
3. Ändert sich der Verbrauch im Laufe der Zeit?

Verfolgen Sie die Ursache des Problems.

Damit Sie die Ursache des Problems (z. B. ein bestimmtes 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. Hier finden Sie 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 die Ursache des Problems zu ermitteln. Sie können im Bildschirm für die Beispielabfrage auf den Tab ENDE zu ENDE klicken, um den Kontexttrace anzuzeigen.

Ermitteln Sie anhand der Top-Clientadressen und der Top-Nutzertabellen 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.

Für Abfragen können Sie 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.

Weitere Informationen zur Verwendung von Tools in Cloud Trace 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 mithilfe der objektrelationalen Zuordnung (Object-relational Mapping, ORM) 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. Um dies zu vermeiden, bietet Query Insights eine Open-Source-Bibliothek mit dem Namen sqlcommenter, einer ORM-Instrumentierungsbibliothek. Diese Bibliothek ist für Entwickler nützlich, die ORMs verwenden, und für Administratoren, die ermitteln möchten, welcher Anwendungscode Leistungsprobleme verursacht.

Wenn Sie ORM und sqlcommenter zusammen verwenden, werden die Tags automatisch erstellt, ohne dass Sie benutzerdefinierten Code ändern oder zu Ihrer Anwendung hinzufügen müssen.

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. Mithilfe dieser Informationen können Sie herausfinden, welcher Anwendungscode 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 ORMs in sqlcommenter wird für verschiedene 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 dessen Verwendung in Ihrem ORM-Framework finden Sie in der sqlcommenter-Dokumentation in GitHub.

Tags mit sqlcommenter manuell hinzufügen

Wenn Sie ORM nicht verwenden, müssen Sie Ihren SQL-Abfragen manuell sqlcommenter-Tags hinzufügen. In der Abfrage 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. Das richtige SQL-Kommentarformat finden Sie in der Dokumentation zu sqlcommenter.

Ausführungszeit und -dauer

Query Insights bietet den Messwert Durchschnittliche Ausführungszeit (ms), der die Gesamtzeit angibt, die alle untergeordneten Aufgaben auf allen parallelen Workern für die Ausführung der Abfrage benötigen. Mit diesem Messwert können Sie die Gesamtressourcennutzung von Datenbanken optimieren, indem Sie Abfragen mit dem höchsten CPU-Overhead ermitteln und optimieren.

Sie können die verstrichene Zeit messen, indem Sie den Befehl \timing auf dem psql-Client ausführen. Damit wird die Zeit gemessen, die zwischen dem Empfang der Abfrage und dem Senden einer Antwort vom PostgreSQL-Server vergeht. Anhand dieses Messwerts können Sie analysieren, warum eine bestimmte Abfrage zu lange dauert, und entscheiden, ob Sie sie optimieren möchten, damit sie schneller ausgeführt wird.

Wenn eine Abfrage von einer einzelnen Aufgabe in einem einzelnen Thread ausgeführt wird, bleiben Dauer und durchschnittliche Ausführungszeit gleich.

Weitere Informationen

• Übersicht über Query Insights
• Abfrageleistung mit erweiterten Query Insights für AlloyDB verbessern
• AlloyDB-Messwerte
• SQL-Kommentarer-Blog: Einführung von Sqlcommenter: Eine Open-Source-Bibliothek mit ORM-Instrumentierung
• Blogpost mit Anleitung: "Abfrage-Tagging mit Sqlcommenter aktivieren"