确定发生延迟的位置

注意 ：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 截止时间超出错误。