Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Auf dieser Seite wird beschrieben, wie Sie Fehler bei Spanner-Komponenten beheben, um die Ursache der Latenz zu finden. Weitere Informationen zu möglichen Latenzpunkten in einer Spanner-Anfrage finden Sie unter Latenzpunkte in einer Spanner-Anfrage.
Prüfen Sie in Ihrer Clientanwendung, die sich auf Ihren Dienst auswirkt, ob die Latenz durch die Client-Umlauflatenz erhöht wird. Prüfen Sie die folgenden Dimensionen aus Ihren clientseitigen Messwerten.
Name der Clientanwendung
Client-Standort (z. B. Compute Engine-VM-Zonen) und Host (d. h. VM-Namen)
Spanner API-Methode
Spanner API-Status
Gruppieren Sie nach diesen Dimensionen, um festzustellen, ob das Problem auf einen bestimmten Client, Status oder eine bestimmte Methode beschränkt ist. Prüfen Sie bei dualen oder multiregionalen Arbeitslasten, ob sich das Problem auf einen bestimmten Client oder eine bestimmte Spanner-Region beschränkt.
Prüfen Sie den Zustand Ihrer Clientanwendung, insbesondere die Computing-Infrastruktur auf der Clientseite (z. B. VM-, CPU- oder Speicherauslastung, Verbindungen und Dateideskriptoren).
Wenn die Client-Umlauflatenz hoch, die GFE-Latenz jedoch niedrig und die Latenz der Spanner API-Anfrage niedrig ist, liegt möglicherweise ein Problem mit dem Anwendungscode vor. Es kann auch auf ein Netzwerkproblem zwischen dem Client und dem regionalen GFE hinweisen. Wenn Ihre Anwendung ein Leistungsproblem hat, das dazu führt, dass einige Codepfade langsam sind, kann sich die Client-Umlauflatenz für jede API-Anfrage erhöhen. Möglicherweise liegt auch ein Problem in der Client-Computing-Infrastruktur vor, das im vorherigen Schritt nicht erkannt wurde.
Gruppieren Sie nach diesen Dimensionen, um festzustellen, ob sich das Problem auf eine bestimmte Datenbank, einen bestimmten Status oder eine bestimmte Methode beschränkt. Prüfen Sie bei dual- oder multiregionalen Arbeitslasten, ob sich das Problem auf eine bestimmte Region beschränkt.
Wenn die GFE-Latenz hoch, die Latenz der Spanner API-Anfrage aber niedrig ist, kann das eine der folgenden Ursachen haben:
Zugriff auf eine Datenbank aus einer anderen Region Diese Aktion kann zu einer hohen GFE-Latenz und einer niedrigen Latenz der Spanner API-Anfrage führen. Beispielsweise hat der Traffic von einem Client in der Region us-east1, der eine Instanz in der Region us-central1 hat, möglicherweise eine hohe GFE-Latenz, aber eine niedrigere Spanner API-Anfragelatenz.
Es gibt ein Problem in der GFE-Ebene. Prüfen Sie im Google Cloud -Status-Dashboard, ob in Ihrer Region laufende Netzwerkprobleme auftreten. Wenn keine Probleme auftreten, öffnen Sie eine Supportanfrage und geben Sie diese Informationen an, damit Supporttechniker bei der Fehlerbehebung beim Google Front End helfen können.
Prüfen Sie die CPU-Auslastung der Instanz.
Wenn die CPU-Auslastung der Instanz über dem empfohlenen Wert liegt, sollten Sie manuell weitere Knoten hinzufügen oder das Autoscaling einrichten. Weitere Informationen finden Sie unter Autoscaling.
Beobachten und beheben Sie mit dem Key Visualizer potenzielle Hotspots oder ungleichmäßige Zugriffsmuster und versuchen Sie, alle Änderungen am Anwendungscode rückgängig zu machen, die in engem Zusammenhang mit dem Zeitraum des Problems stehen.
Prüfen Sie, ob sich die Zugriffsmuster geändert haben.
Verwenden Sie die Verfahren unter Älteste aktive Abfragen, um alle Ausgabenabfragen zu sehen, die zu einem Leistungsengpass führen könnten, und brechen Sie die Abfragen bei Bedarf ab.
Verwenden Sie die Verfahren in den Abschnitten zur Fehlerbehebung in den folgenden Themen, um das Problem mithilfe von Spanner-Inspektionstools weiter zu beheben:
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-11 (UTC)."],[],[],null,["# Identify where latency occurs\n\n| **Note:** [OpenCensus is deprecated](https://opentelemetry.io/blog/2023/sunsetting-opencensus/). We recommend using OpenTelemetry to capture and visualize Spanner observability metrics. For more information, see [Capture custom client-side metrics using OpenTelemetry](/spanner/docs/capture-custom-metrics-opentelemetry).\n\nThis page describes how to troubleshoot Spanner components to find the\nsource of the latency. To learn more about possible latency points in a\nSpanner request, see\n[Latency points in a Spanner request](/spanner/docs/latency-points).\n\n1. In your client application that affects your service, confirm there's a\n latency increase from client round-trip latency. Check the following dimensions\n from your client-side metrics.\n\n - Client Application Name\n - Client locality (for example, Compute Engine VM zones) and Host (that is, VM names)\n - Spanner API method\n - Spanner API status\n\n Group by these dimensions to see if the issue is limited to a specific\n client, status, or method. For dual-region or multi-regional workloads, see\n if the issue is limited to a specific client or Spanner region.\n2. Check your client application health, especially the computing\n infrastructure on the client side (for example, VM, CPU, or memory\n utilization, connections, file descriptors, and so on).\n\n3. Check latency in Spanner components:\n\n a. Check client round-trip latency [with OpenTelemetry](/spanner/docs/capture-custom-metrics-opentelemetry#capture-client-round-trip-latency)\n or [with OpenCensus](/spanner/docs/capture-visualize-latency-opencensus#capture_and_visualize_client_round-trip_latency).\n\n b. Check Google Front End (GFE) latency [with OpenTelemetry](/spanner/docs/capture-custom-metrics-opentelemetry#capture-gfe-latency)\n or [with OpenCensus](/spanner/docs/capture-visualize-latency-opencensus#capture_and_visualize_gfe_latency).\n\n c. Check Spanner API request latency [with OpenTelemetry](/spanner/docs/capture-custom-metrics-opentelemetry#capture-spanner-api-request-latency)\n or [with OpenCensus](/spanner/docs/capture-visualize-latency-opencensus#capture_and_visualize_api_request_latency).\n\n If you have high client round-trip latency, but low GFE latency, and a low\n Spanner API request latency, the application code might\n have an issue. It could also indicate a networking issue between the client\n and regional GFE. If your application has a performance issue that causes\n some code paths to be slow, then the client round-trip latency for each API\n request might increase. There might also be an issue in the client computing\n infrastructure that was not detected in the previous step.\n4. Check the following dimensions for\n [Spanner metrics](/spanner/docs/latency-metrics):\n\n - Spanner Database Name\n - Spanner API method\n - Spanner API status\n\n Group by these dimensions to see if the issue is limited to a specific\n database, status, or method. For dual-region or multi-regional workloads,\n check to see if the issue is limited to a specific region.\n\n If you have a high GFE latency, but a low Spanner API request\n latency, it might have one of the following causes:\n - Accessing a database from another region. This action can lead to high GFE\n latency and low Spanner API request latency. For example,\n traffic from a client in the `us-east1` region that has an instance in the\n `us-central1` region might have a high GFE latency but a lower\n Spanner API request latency.\n\n - There's an issue at the GFE layer. Check the [Google Cloud Status Dashboard](https://status.cloud.google.com/)\n to see if there are any ongoing networking issues in your region. If there\n aren't any issues, then open a support case and include this information so\n that support engineers can help with troubleshooting the GFE.\n\n5. [Check the CPU utilization of the instance](/spanner/docs/cpu-utilization).\n If the CPU utilization of the instance is above the recommended level, you\n should manually add more nodes, or set up auto scaling. For more information,\n see [Autoscaling overview](/spanner/docs/autoscaling-overview).\n\n6. Observe and troubleshoot potential hotspots or unbalanced access patterns\n using [Key Visualizer](/spanner/docs/key-visualizer)\n and try to roll back any application code changes that strongly correlate\n with the issue timeframe.\n\n | **Note:** We recommend you follow [Schema design best practices](/spanner/docs/schema-design) to ensure your access is balanced across Spanner computing resources.\n7. Check any traffic pattern changes.\n\n8. Check [Query insights](/spanner/docs/using-query-insights) and\n [Transaction insights](/spanner/docs/use-lock-and-transaction-insights) to\n see if there might be any query or transaction performance bottlenecks.\n\n9. Use procedures in [Oldest active queries](/spanner/docs/introspection/oldest-active-queries)\n to see any expense queries that might cause a performance bottleneck and\n cancel the queries as needed.\n\n10. Use procedures in the troubleshooting sections in the following topics to\n troubleshoot the issue further using Spanner introspection\n tools:\n\n - [Query statistics](/spanner/docs/introspection/query-statistics)\n - [Read statistics](/spanner/docs/introspection/read-statistics)\n - [Transaction statistics](/spanner/docs/introspection/transaction-statistics)\n - [Lock statistics](/spanner/docs/introspection/lock-statistics)\n\nWhat's next\n-----------\n\n- Now that you've identified the component that contains the latency, explore the problem further using OpenCensus. For more information, see [Capture custom client-side metrics using OpenTelemetry](/spanner/docs/capture-custom-metrics-opentelemetry) or [with OpenCensus](/spanner/docs/capture-visualize-latency-opencensus).\n- Learn how to use [metrics](/spanner/docs/latency-metrics) to diagnose latency.\n- Learn how to [troubleshoot Spanner deadline exceeded errors](/spanner/docs/deadline-exceeded)."]]
