排查 Spanner 截止时间超出错误

本页面简要介绍了 Spanner 超出期限的错误： 问题的定义、出现原因、如何进行问题排查和解决。

访问 Spanner API 时，请求可能会由于以下原因而失败： DEADLINE_EXCEEDED 个错误。此错误表示响应尚未 在配置的超时期限内收到的所有请求。

导致“超出期限”错误的原因可能有很多种，例如 Spanner 实例过载、架构未经优化或未经优化 查询。本页面介绍了有关超出截止期限错误的常见情况 并指导您如何调查和解决这些问题。

Spanner 的截止期限和重试理念

Spanner 的截止时间和重试理念与其他许多 系统。在 Spanner 中，您应将超时截止时间指定为 响应处于可用状态的最长时间。人为设置一个 只是立即重试同一操作的截止期限较短 推荐，因为这会导致操作无法完成。在 在这种情况下，不建议采取以下策略和操作；他们 会适得其反，使 Spanner 的内部重试失败 行为：

  • 设置的截止期限过短。也就是说，操作 能够灵活应对偶尔的尾延迟时间增加，无法在该时间之前完成 超时。而应将截止期限设置为 非常有用。

  • 设置太长的截止期限，并在 超过截止时间。这会导致重试和每次尝试都浪费工作。在 否则可能会给实例带来大量额外负载。

什么是“已超出截止日期”错误？

当您使用其中一个 Spanner 客户端库时， 底层 gRPC 层负责通信、编组、解组， 实施新政策截止期限可让您的应用指定 愿意等待请求完成，然后再终止该请求 “已超出期限”错误。

超时配置指南演示了 如何在每个受支持的 Spanner 中指定截止期限（或超时） 客户端库。Spanner 客户端库使用默认超时 和重试以下配置文件中定义的政策设置：

如需详细了解 gRPC 时限，请参阅 gRPC 和时限。

如何调查和解决超出截止日期的常见错误

对于以下问题类型，您可能会遇到 DEADLINE_EXCEEDED 错误：

Data Access API 问题

必须为您的 Cloud Spanner 实例 避免数据访问 API 问题。以下部分 介绍了如何调查和解决各种 Data Access API 问题。

检查 Spanner 实例的 CPU 负载

当 CPU 利用率超过 建议的状况良好判断阈值。您可以查看 在 Monitoring 控制台中查看 Spanner CPU 利用率 提供的资源您还可以创建提醒 根据实例的 CPU 利用率计算得出。

解决方法

如需了解降低实例 CPU 利用率的步骤，请参阅降低 CPU 利用率。

查看请求的端到端延迟时间细分

当请求从客户端传输到 Spanner 服务器并返回时， 还需要进行多个网络跃点：从客户端库到 Google Front End (GFE)；从 GFE 到 Spanner API 前端； 最后从 Spanner API 前端 Spanner 数据库。如果上述任一位置出现网络问题 则您可能会看到“已超出期限”错误。

您可以捕获每个阶段的延迟时间。如需了解详情，请参阅 Spanner 请求中的延迟时间点。 如需了解 Spanner 中发生延迟的位置，请参阅 确定 Spanner 中发生延迟的位置。

解决方法

获得延迟时间细分数据后，您可以 使用指标来诊断延迟时间，了解 并找出解决办法

Data API 问题

Spanner Data API 的某些非最佳使用模式可能 会导致“超出期限”错误。本部分将提供有关如何 以检查是否存在这些非最佳使用模式。

检查是否存在开销高昂的查询

尝试运行未在配置的超时内执行且开销大的查询 则可能会导致“已超出期限”错误。部分 成本高昂的查询的示例包括但不限于 大型表、多个大型表的交叉联接，或使用 对非键列执行谓词（也称为全表扫描）。

您可以使用查询统计信息表检查开销大的查询 和交易统计信息表格。 这些表显示了与运行缓慢的查询和事务有关的信息，例如 平均读取行数、平均读取字节数和 扫描的行数等。此外，您还可以生成查询执行计划 以进一步检查查询的执行方式。

解决方法

如需优化查询，请参阅 SQL 查询最佳实践指南。 您还可以使用从上述统计信息表格获得的数据 优化查询和更改架构的执行计划 写入数据库这些最佳实践有助于缩短 语句，可能有助于消除超出截止时间的错误。

检查锁争用

Spanner 事务需要获取锁 以高吞吐量运行的应用可能会导致事务 争用相同的资源，会导致获取锁的等待时间增加， 从而影响整体效果这可能会导致超出 读取或写入请求

您可以通过以下方式找到长延迟时间读写事务的根本原因： 使用锁定统计信息表格 并参阅以下博文。 在锁定统计信息表格中，您可以找到具有最高 锁定等待时间。

请参阅这篇锁定冲突问题排查指南 介绍了如何查找访问相关列的交易 锁定冲突。您还可以查看哪些交易 请参阅事务代码问题排查指南中的说明。

解决方法

采取这些最佳实践 以减少锁争用此外，请使用只读事务 ，以避免与写入发生锁冲突。使用 读写事务应预留用于写入或混合读写工作流。 按照这些步骤进行操作应该可以缩短事务的总体延迟时间 执行时间以及缩短期限超出期限的错误。

检查是否存在未经优化的架构

在为 Spanner 设计最佳数据库架构之前 数据库时，您应该考虑将在数据库内执行的查询 您的数据库。次优架构可能会导致运行时出现性能问题 部分查询。这些性能问题可能会导致请求无法完成 在配置的时限内完成。

解决方法

最佳架构设计取决于对 您的数据库。架构设计最佳实践和 SQL 都应遵循最佳实践指南，无论 架构细节遵循这些指南，可避免使用最常见的架构， 设计问题。导致性能不佳的其他根本原因 您的主键选择、 表格布局（请参阅使用交错表格更快地访问）， 架构设计（请参阅优化架构以提高性能）； 集群内配置的节点的性能 Spanner 实例（请参阅 Spanner 性能概览）。

检查热点

由于 Spanner 是一个分布式数据库，因此架构设计 都需要考虑热点问题例如，为单调的 增加列数将限制 Spanner 的拆分数量 来均匀分配工作负载这些瓶颈可能会导致 超时。此外，您还可以使用 Key Visualizer 排查由热点引起的性能问题。

解决方法

请参阅上一部分检查是否存在未经优化的分辨率 架构。重新设计 数据库架构并使用交错索引 以避免可能导致热点的索引。如果按照上述步骤 如需缓解此问题，请参阅“选择主键以防止出现热点”指南。 最后，避免不理想的流量模式，例如大范围读取， 防止基于负载的拆分

检查是否存在配置错误的超时

客户端库为 Spanner。不过，这些默认配置可能需要 根据具体工作负载进行调整。您应观察一下 并根据您的具体使用场景调整截止时间。

解决方法

超时的默认设置适用于大多数用例。用户可以 覆盖这些配置（请参阅自定义超时和重试指南）， 但不建议使用比默认超时更激进的超时值。 如果您决定更改超时时间，请将其设置为在 并愿意等待结果您可以试验 配置的超时，但绝不能设置短于实际 因为这会导致操作 重试的次数。

Admin API 问题

与 Data API 请求相比，Admin API 请求是成本高昂的操作。 CreateInstance、CreateDatabase 或 CreateBackups 等管理员请求可以 需要几秒钟的时间才能返回响应。Spanner 客户端 库为 instance 和数据库 管理员请求。这是为了确保服务器有机会完成 请求，然后再重试或失败。

解决方法

如果您使用的是 Google Spanner 客户端库 访问管理员 API，请确保客户端库已更新并使用最新的 版本。如果您是通过 客户端库，确保您没有设置更严格的截止期限 设置高于实例的默认设置（60 分钟） 和数据库 管理员请求。

Google Cloud 控制台问题

通过 Google Cloud 控制台 Spanner Studio 页面发出的查询无法 超过五分钟。如果您创建了一个需要 5 个以上查询时间 分钟，您会看到以下错误消息：

“Google Cloud 控制台的截止时间已过”错误消息的屏幕截图

后端将取消失败的查询，事务可能会回滚 （如果需要的话）。

解决方法

您可以使用 SQL 查询最佳实践指南重写查询。

Dataflow 问题

在 Apache Beam 中，默认的超时配置为 2 小时 15 秒 用于提交操作当出现以下情况时，这些配置允许执行耗时较长的操作： （与独立客户端库的截止时间超时相比）不过， 但当工作项执行时， 过大。如有必要，您可以自定义 Apache Beam 提交 超时配置。

解决方法

如果第 ReadFromSpanner / Execute query / Read from Spanner / Read from Partitions 步中出现“超出截止日期”错误，请检查 查询统计信息表 找出哪个查询扫描了大量行。然后将 来尝试减少执行时间。

另一个示例展示了超出 Dataflow 截止时间的错误 以下异常消息：

exception:
     org.apache.beam.sdk.util.UserCodeException:
     com.google.cloud.spanner.SpannerException: DEADLINE_EXCEEDED:
     io.grpc.StatusRuntimeException: DEADLINE_EXCEEDED: deadline exceeded after
     3599.999905380s.
     [remote_addr=batch-spanner.googleapis.com/172.217.5.234:443] at
 org.apache.beam.runners.dataflow.worker.GroupAlsoByWindowsParDoFn$1.output(GroupAlsoByWindowsParDoFn.java:184)

导致此超时的原因是工作项过大。在前面的示例中， 以下两条建议可能会有所帮助。首先，您可以尝试启用 shuffle 服务（如果尚未启用）。其次，您可以尝试调整 配置（例如 maxPartitions 和 partitionSizeBytes.如需了解详情，请参阅 PartitionOptions 来尝试缩减工作项大小如需查看实现方法的示例，请参阅 Dataflow 模板中。

超出期限的其他问题排查资源

如果您在完成以下设置后仍看到 DEADLINE_EXCEEDED 错误： 问题排查步骤，请创建支持请求 会遇到以下情况：

  • Google Front End 延迟较高，但 Spanner API 请求延迟较低
  • Spanner API 请求延迟时间较长，但查询延迟时间较短

您还可以参阅以下问题排查资源：