Abfrageleistung mit Query Insights verbessern

Mit dem Query Insights-Dashboard können Sie Leistungsengpässe bei Abfragen erkennen und analysieren, Abfragepläne prüfen und Anfragen mit hoher Latenz in Ihren AlloyDB for PostgreSQL-Instanzen verfolgen. Eine Übersicht über diese Funktion finden Sie unter Query Insights – Übersicht.

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

Hinweis

Wenn Sie oder andere Nutzer den Abfrageplan aufrufen oder End-to-End-Tracing durchführen müssen, benötigen Sie dafür bestimmte IAM-Berechtigungen (Identity and Access Management). Sie können eine benutzerdefinierte Rolle erstellen und ihr die erforderlichen IAM-Berechtigungen hinzufügen. Anschließend können Sie diese Rolle jedem Nutzerkonto hinzufügen, das Query Insights zur Fehlerbehebung 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 entweder auf der Übersichtsseite des Clusters 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 mit den 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 sind für alle verbundenen Lesepoolinstanzen und deren 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 Cloud Assist aktivieren, beträgt die Datenaufbewahrungsrichtlinie für Abfragemesswerte 30 Tage.

Query Insights-Konfiguration bearbeiten

Query Insights sind auf AlloyDB-Instanzen standardmäßig 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 Query Insights.

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

5. Bearbeiten Sie die Felder für Query Insights:

   1. Wenn Sie das Standardlimit von 1.024 Byte für die Länge von Abfragen ändern möchten, die AlloyDB analysieren soll, geben Sie im Feld Abfragelängen 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. Wenn Sie die Feature-Sets von Query Insights anpassen möchten, ändern Sie die folgenden Optionen:

      • Abfrageplanstichproben: Klicken Sie dieses Kästchen an, um die Vorgänge zu visualisieren, die zum Ausführen einer Abfragestichprobe verwendet werden. Die Abtastrate bestimmt die maximale Anzahl von Abfragen, die AlloyDB pro Minute für die Instanz pro Knoten abtasten kann.

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

      • Client-IP-Adressen speichern: Aktivieren Sie dieses Kästchen, um zu erfahren, woher Ihre Abfragen stammen, und um diese Informationen zu gruppieren, um Messwerte auszuführen.

      • Anwendungs-Tags speichern: Setzen Sie ein Häkchen, um zu erfahren, welche mit Tags versehenen Anwendungen Anfragen stellen, und um diese Informationen zu 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 den folgenden Befehl aus, um die gcloud CLI zu initialisieren:

   gcloud init
   

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

   gcloud auth application-default login
   

   Wenn Sie Cloud Shell verwenden, ist dies 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:

• INSTANCE: die ID der zu aktualisierenden Instanz
• CLUSTER: die ID des Clusters der Instanz
• PROJECT: die ID des Projekts des Clusters
• REGION: die Region des Clusters, z. B. us-central1
• QUERY_LENGTH: die Länge der Abfrage, die zwischen 256 und 4.500 liegt
• QUERY_PLANS: 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 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.
• --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. Geben Sie 0 ein, um die Stichprobenerhebung zu deaktivieren. 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 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. 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

Warnung: Damit der Terraform-Zustand konsistent bleibt, sollten Sie Konfigurationen direkt in Ihren Terraform-Dateien aktualisieren. Wenn Sie manuelle Änderungen mit der Google Cloud Console, der gcloud CLI oder der REST API vornehmen, können die folgenden Probleme auftreten:

• API-Fehler
• Unbefristete Unterschiede
• Überschriebene Änderungen während terraform apply

Wenn Sie Terraform zum Konfigurieren von Query Insights verwenden 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 zusammen erfasst werden. Der Standardwert ist 5. Jede Ganzzahl zwischen 0 und 20 ist gültig.

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

  Die Beispielinstanzkonfiguration mit der hinzugefügten Query Insights-Konfiguration 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 Beobachtbarkeitseinstellungen für Ihre AlloyDB-Instanz konfiguriert. Eine vollständige Liste der Parameter für diesen Aufruf finden Sie unter Methode: projects.locations.clusters.instances.patch.

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

Ersetzen Sie folgende Werte in den Anfragedaten:

• CLUSTER_ID: Die ID des Clusters, den Sie erstellen. 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: der Name der primären Instanz, die Sie erstellen möchten.

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

PATCH https://alloydb.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION_ID/clusters/CLUSTER_ID/instances/INSTANCE_ID?updateMask=observabilityConfig.enabled

Der JSON-Anfragetext, mit dem alle Beobachtbarkeitsfelder konfiguriert werden, sieht so aus:

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

Abfrageleistung verbessern

Mit Query Insights können Sie Fehler in AlloyDB-Abfragen beheben, um nach Leistungsproblemen zu suchen. 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 Query Insights können Sie Probleme mit der Abfrageleistung erkennen und analysieren. So beheben Sie Probleme mit Abfragen mithilfe von Query Insights:

• Datenbanklast für alle Abfragen ansehen
• Problematische Abfrage oder problematisches Tag identifizieren
• Abfrage oder Tag ansehen, um Probleme zu ermitteln
• Einen Trace untersuchen, der von einer Beispielabfrage generiert wurde

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 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 werden 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 entweder 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 die Abfragen in der Tabelle nach der Gesamtausführungszeit innerhalb des ausgewählten Zeitfensters sortiert.

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

• Abfragestring. Der normalisierte Abfragestring. In Query Insights werden standardmäßig nur 1.024 Zeichen im Abfragestring angezeigt.

  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 Unteraufgaben auf allen parallelen Workern benötigen, um die Abfrage abzuschließen. 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, d. h. $1, $2 usw. ersetzen die Werte der Literalkonstanten. 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. Dabei kann es sich beispielsweise um unerwartete Ereignisse wie Spitzen bei den Geschäftsanalyse-Tags um 13:00 Uhr handeln. Oder Sie sehen ein unerwartetes Wachstum bei einem Trend zur Zahlungsbearbeitung in der letzten Woche.

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 Abschlusszeit an der Minutengrenze anhand der tatsächlich verstrichenen Zeit.

Wählen Sie im Query Insights-Dashboard die Option TAGS aus, um die Tag-Tabelle anzuzeigen. 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 Unteraufgaben auf allen parallelen Workern benötigen, um die Abfrage abzuschließen. 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 der ausgewählten Abfrage angezeigt:

Wenn Sie ein Tag ausgewählt haben, wird eine Übersicht des ausgewählten Tags 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 mit der höchsten Last gefunden haben, können Sie die Details weiter aufschlüsseln.

Latenz in einem 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.

Klicken Sie auf die Punkte im Diagramm Beispielabfragepläne, um Details zum Beispielabfrageplan aufzurufen. Die meisten ausgeführten Abfragepläne werden angezeigt, allerdings nicht alle. Beachten Sie, dass AlloyDB for PostgreSQL Abfragen automatisch abtastet. Je häufiger eine Abfrage ausgeführt wird, desto wahrscheinlicher ist es, dass sie in die Stichprobe aufgenommen wird. Wenn Sie weitere Beispielabfragepläne ansehen möchten, folgen Sie der Anleitung unter Query Insights-Konfiguration bearbeiten, um die maximale Abtastrate zu erhöhen.

Wenn Sie die erweiterten Details eines Abfrageplans aufrufen, sehen Sie ein Modell aller Vorgänge in diesem Plan. 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, tatsächliche Schleifen und Planzeilen angezeigt.

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?

Von einer Beispielabfrage generierten Trace prüfen

Zusätzlich zum Anzeigen des Beispielabfrageplans können Sie mit Query Insights einen kontextbezogenen End-to-End-Anwendungs-Trace für eine Beispielabfrage aufrufen. Dieser Trace kann Ihnen helfen, die Quelle einer problematischen Abfrage zu identifizieren, indem die Datenbankaktivität für eine bestimmte Anfrage angezeigt wird. Außerdem werden Logeinträge, die die Anwendung während der Anfrage an Cloud Logging sendet, mit dem Trace verknüpft, was Ihnen bei der Untersuchung hilft.

So rufen Sie den kontextbezogenen Trace auf:

1. Klicken Sie im Bereich Beispielabfrage auf den Tab End-to-End-Trace. Auf diesem Tab wird ein Gantt-Diagramm mit den Spans für den von der Abfrage generierten Trace angezeigt. Spans sind Datensätze einzelner Vorgänge.

2. Klicken Sie auf den Span, um weitere Details zu den einzelnen Spans aufzurufen, z. B. Attribute und Metadaten.

Sie können sich den Trace auch auf der Seite Trace Explorer ansehen. Klicken Sie dazu auf In Cloud Trace ansehen. Weitere Informationen zur Verwendung der Seite Trace Explorer zum Untersuchen Ihrer Trace-Daten finden Sie unter Traces suchen und untersuchen.

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 dieses Problem zu beheben, bietet Query Insights eine Open-Source-Bibliothek namens sqlcommenter, eine 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 Unteraufgaben auf allen parallelen Workern benötigen, um die Abfrage abzuschließen. Mit diesem Messwert können Sie die Gesamtauslastung der Datenbankressourcen optimieren, indem Sie Abfragen mit dem höchsten CPU-Overhead finden und optimieren.

Wenn Sie die verstrichene Zeit sehen möchten, können Sie die Dauer einer Abfrage messen, indem Sie den Befehl \timing auf dem psql-Client ausführen. Es wird die Zeit gemessen, die zwischen dem Empfang der Abfrage und dem Senden einer Antwort durch den PostgreSQL-Server vergeht. Mit diesem Messwert 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 mit einem einzelnen Thread abgeschlossen wird, bleiben die Dauer und die durchschnittliche Ausführungszeit gleich.

Erweiterte Query Insights-Funktionen für AlloyDB aktivieren

Das Dashboard für erweiterte Query Insights-Funktionen für AlloyDB ist in das Standard-Dashboard für Query Insights integriert. Weitere Informationen zum Aktivieren erweiterter Query Insights-Funktionen finden Sie unter Abfrageleistung mit erweiterten Query Insights-Funktionen verbessern.

Nächste Schritte

• Query Insights – Übersicht
• Abfrageleistung mit erweiterten Query Insights-Funktionen 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"