确定发生延迟的位置

注意 ：OpenCensus 已弃用。 我们建议使用 OpenTelemetry 来捕获并直观呈现 Spanner 可观测性指标。如需了解详情，请参阅使用 OpenTelemetry 检查 Spanner 组件中的延迟时间。

本主题介绍了如何对 Spanner 组件进行问题排查，以找出延迟的原因。如需详细了解 Spanner 请求中可能的延迟时间点，请参阅 Spanner 请求中的延迟时间点。

1. 在影响服务的客户端应用中，确认客户端往返延迟时间的延迟时间是否有所增加。请查看客户端指标中的以下维度。

   • 客户端应用名称
   • 客户端位置（例如 Compute Engine 虚拟机区域）和主机（即虚拟机名称）
   • Spanner API 方法
   • Spanner API 状态

   按这些维度进行分组，查看问题是否仅限于特定客户端、状态或方法。对于多区域工作负载，请查看问题是否仅限于特定客户端或 Spanner 区域。

2. 检查客户端应用的运行状况，尤其是客户端的计算基础架构（例如虚拟机、CPU 或内存利用率、连接、文件描述符等）。

3. 检查 Spanner 组件中的延迟时间：

   a. 使用 OpenTelemetry 或使用 OpenCensus 检查客户端往返延迟时间。

   b. 使用 OpenTelemetry 或使用 OpenCensus 检查 Google Front End (GFE) 延迟时间。

   c. 使用 OpenTelemetry 或使用 OpenCensus 检查 Spanner API 请求延迟时间。

   如果客户端往返延迟较高，但 GFE 延迟较低，且 Spanner API 请求延迟较低，则应用代码可能存在问题。这也可能表示客户端与区域 GFE 之间存在网络问题。如果您的应用存在导致某些代码路径变慢的性能问题，则每个 API 请求的客户端往返延迟可能会增加。客户端计算基础架构中可能还存在上一步中未检测到的问题。

4. 检查 Spanner 指标的以下维度：

   • Spanner 数据库名称
   • Spanner API 方法
   • Spanner API 状态

   按这些维度进行分组，查看问题是否仅限于特定数据库、状态或方法。对于多区域工作负载，请检查问题是否仅限于特定区域。

   如果 GFE 延迟时间较高，但 Spanner API 请求延迟时间较短，则可能是因为以下原因之一：

   • 从其他区域访问数据库。此操作可能会导致 GFE 延迟较高，Spanner API 请求延迟较低。例如，对于来自 us-east1 区域中且在 us-central1 区域中有实例的客户端的流量，其 GFE 前端延迟时间可能较高，但 Spanner API 请求延迟时间较短。

   • GFE 层存在问题。请查看 Google Cloud 状态信息中心，了解您所在的区域是否正在解决任何网络问题。如果没有任何问题，请提交支持请求并附上此信息，以便支持工程师帮助您排查 GFE 问题。

5. 检查实例的 CPU 利用率。 如果实例的 CPU 利用率高于建议的水平，则应手动添加更多节点或设置自动伸缩。如需了解详情，请参阅自动扩缩概览。

6. 使用 Key Visualizer 观察潜在热点或不平衡访问模式并对其进行问题排查，并尝试回滚与问题时间范围密切相关的任何应用代码更改。

   注意 ：我们建议您遵循架构设计最佳实践，以确保在 Spanner 计算资源之间平衡访问权限。

7. 检查流量模式更改。

8. 查看查询数据分析和事务数据分析，查看是否存在任何查询或事务性能瓶颈。在大多数情况下，您需要遵循 Spanner 最佳实践来优化查询或事务。

9. 使用最早的活跃查询中的过程查看可能导致性能瓶颈的任何费用查询，并根据需要取消查询。

10. 请按照以下主题中“问题排查”部分中的流程，使用 Spanner 自省工具进一步排查问题：

    • 查询统计信息
    • 读取统计信息
    • 事务统计信息
    • 锁定统计信息

后续步骤

• 现在您已经确定了包含延迟的组件，接下来请使用 OpenCensus 进一步探索该问题。如需了解详情，请参阅使用 OpenTelemetry 检查 Spanner 组件中的延迟时间或使用 OpenCensus。
• 了解如何使用metrics来诊断延迟时间。
• 了解如何排查 Spanner 超出截止时间的错误。