排查延迟时间问题

与任何数据库系统一样，Bigtable 也可能会遇到延迟时间问题。本文档讨论了 Bigtable 中延迟时间问题的常见原因，并介绍了如何排查这些问题。

使用以下部分中的问题排查步骤诊断和解决 Bigtable 延迟时间问题：

• 客户端延迟时间
• 服务器端延迟时间

了解高延迟原因

以下因素会导致 Bigtable 出现延迟问题：

• 服务器延迟时间。服务器延迟时间的测量从 Bigtable 收到请求后开始，到 Bigtable 将最后一个字节的数据发送到客户端后停止。对于数据量较大的请求，客户端响应处理能力会影响服务器延迟时间。
• 操作延迟时间衡量 Bigtable 操作的总端到端时间，包括所有重试。此指标跟踪从客户端到 Bigtable 再返回客户端的往返时间。应用的延迟时间、网络连接、Bigtable 客户端库延迟时间和服务器延迟时间都会影响操作延迟时间。
• 工作负载和请求模式可能会增加延迟时间，这不仅是因为基础架构问题，还因为应用请求的工作模式发生了变化。例如，由于最近的数据导入或应用逻辑更改，之前扫描 100 行的动态生成的扫描查询现在会扫描 100 万行。虽然系统可能在高效运行，但单次操作的工作量显著增加会导致执行时间延长，Bigtable 会将其视为延迟时间增加。

准备工作

如需排查高延迟问题，请执行以下任务：

• 为客户端库启用客户端指标，以优化性能并解决问题。
• 为最大限度地减少网络延迟时间，请验证您的应用是否与 Bigtable 集群位于同一可用区。这会缩短应用与集群之间的网络距离，从而缩短请求的响应时间。
• 收集有关 Bigtable 环境的以下信息：
  项目 ID
  实例 ID
  集群 ID
  表名称
• 收集有关客户端环境的以下信息：
  项目 ID（如果与 Bigtable 项目 ID 不同）
  客户端区域
  客户端库或框架
• 收集以下与问题相关的信息：
  问题发生的时间范围，包括时区信息
  问题开始之前观察到的延迟时间值
  延迟时间较长的 API 方法的名称
  在问题发生期间观察到的延迟时间值
  如果问题现在没有发生，那么在问题发生后观察到的延迟时间是多少
  问题期间观察到的错误
  为缓解问题而采取的措施
  所有可用指标

排查延迟时间问题

如果您在 Bigtable 中遇到延迟时间问题，请按照以下步骤排查问题：

1. 检查服务器延迟时间：使用Google Cloud 控制台中的“监控”页面查看服务器延迟时间。如需了解详情，请参阅使用 Cloud Monitoring 进行监控。 检查实例的延迟时间。如果实例包含多个集群，请按集群对指标进行切片。如果您在读取延迟时间或写入延迟时间图表中或在客户端指标中观察到延迟时间增加，请按照本文档排查服务器延迟时间问题部分中的服务器延迟时间问题排查步骤进行操作。
2. 检查客户端延迟时间：启用客户端指标后，在 Cloud Monitoring Metrics Explorer 中搜索 bigtable.googleapis.com/client。查看可用的客户端指标。如果您发现客户端指标中的延迟时间有所增加，但服务器端指标中的延迟时间没有增加，请检查您的应用和网络连接。如需了解详情，请参阅本文档的排查客户端延迟时间问题部分。

下图显示了排查 Bigtable 延迟时间增加问题的过程：

图 1. 排查 Bigtable 延迟时间问题的过程（点击可放大）。

排查客户端延迟时间问题

请按照以下步骤排查客户端延迟时间问题。

准备工作

在开始排查客户端延迟时间问题之前，请完成以下任务：

• 在 Bigtable 中启用客户端指标。
• 如果您使用的是 Java 客户端 2.17.1 或更早版本，请启用通道预热。 从 2.18.0 版开始，渠道刷新默认处于启用状态。
• 通过迭代确定工作负载的最佳连接池大小。通道不足或过多可能会导致尝试延迟时间过长。

检查应用阻塞延迟时间

在 Google Cloud 控制台中查看 Application Blocking Latencies 指标，并执行以下操作之一：

• 如果应用阻塞延迟时间较长，并且与报告的延迟时间增加相对应，请重点排查客户端问题。
• 如果应用阻塞延迟时间较长，并且客户端托管在Google Cloud 基础设施（例如 GKE 或 Compute Engine）上，请上报给相应的 Google Cloud 支持团队。
• 如果应用阻塞延迟时间较低，且 Bigtable 服务延迟时间也较低，则延迟时间瓶颈可能位于网络或流量路径的中间组件（例如网络或 Google 前端）。考虑上报给 Google Cloud网络团队，让他们协助您进行完整的数据包捕获，以找出延迟瓶颈。

解决操作延迟时间过长的问题

1. 如果 connectivity_error_count 较高，则应用在访问 Google 前端时遇到问题。设置较短的 RPC 超时，以便请求可以在不同的渠道上重试。
   • 如果 RPC 超时过低，也可能会导致操作延迟时间过长。确定正常操作期间的典型 P99 RPC 超时。将 RPC 超时值设置为更接近此基准的值有助于优化性能。
2. 如果 retry_count 较高，请检查 attempt_latencies 状态标记。如果尝试失败并显示 DEADLINE_EXCEEDED 错误，则请求截止时间与平均 attempt_latencies 相比过短。

解决 gRPC 线程上排队的请求

如果没有任何指标超出正常范围，则请求可能会在 gRPC 线程上排队。出现这种情况可能由以下原因所致：

• 通道池大小过小，请求在 gRPC 通道中排队。如需了解详情，请参阅缓冲请求。
• 客户端虚拟机的 CPU 使用率较高。CPU 使用率过高还会导致客户端中的请求排队。

注意：对于 Java 2.21.0 及更高版本，client_blocking_latencies 指标还包括 gRPC 通道上排队的请求的延迟时间。

排查服务器延迟时间问题

请按照以下步骤排查服务器端延迟时间问题。

确定集群是否过载

1. 查看 Read requests 和 Write requests 图表，了解 QPS 的变化。
2. 查看 Node count 图表，了解节点数量的变化。
3. 检查 Read throughput 和 Write throughput 图表，看看带宽是否有所增加。如需了解详情，请参阅了解性能。
4. 如需了解如何按应用配置文件、方法和表来确定 CPU 的使用情况，以排查性能问题，请参阅您的 Cloud Bigtable 集群在哪些方面消耗了 CPU？博文。
5. 增加受影响集群中的节点数。如需了解详情，请参阅手动添加或移除节点和自动扩缩。验证平均 CPU 利用率是否保持在建议的阈值以下。

检查是否存在热点

与和节点关联的其他片相比，热片使用的节点 CPU 百分比比例过大。这种不均衡的使用情况可能是由于对行范围的请求量意外增加或架构设计缺陷造成的。这种不均衡的节点使用可能会导致更高的延迟时间和复制延迟，称为热点。

1. 观察 CPU utilization (hottest node) high granularity 图表中的热点。
2. 如需识别热片，请使用热片或 Key Visualizer 工具。
3. 与集群级 CPU 利用率过高（通常可以通过添加更多节点 [横向伸缩] 来缓解）不同，热点可能需要其他缓解技术。这些方法包括更改行键的构造方式或更改架构。如需了解详情，请参阅消除 Cloud Bigtable 中的热点博文。

解决 QPS 较低时的延迟时间问题

Bigtable 最适合频繁访问的大型表。如果您在空闲一段时间后发送请求，则可能会在 Bigtable 重新建立连接时观察到高延迟。

1. 如果 Read requests 和 Write requests 图表显示 QPS 较低，则响应时间会较慢。
2. 按照冷启动和低 QPS 中的最佳实践缓解冷启动问题。

评估请求效率

使用访问模式页面和查询统计信息评估请求效率：

• 使用 Google Cloud 控制台中的访问模式页面，监控一段时间内读写查询类型的细分（例如点读取、短扫描、反向扫描、稀疏读取和批量读取），并针对表和应用配置文件比较扫描的行数和看到的单元格数与返回的行数和发送的单元格数。如需了解详情，请参阅分析访问模式。
• 使用查询统计信息来检查各个读取请求的所显示行数与返回行数的比率，以及所显示单元数与返回单元数的比率。通过重新审视查询句式、过滤条件或架构设计，提高请求效率。如需了解详情，请参阅获取查询统计信息。

检查配置或应用配置文件更改

如果节点数量和吞吐量保持不变，但平均 CPU 利用率增加，这可能是由于复制或垃圾回收策略发生变化所致。如需了解详情，请参阅复制和性能。还原对复制或垃圾回收所做的任何配置更改。

上报给 Bigtable 支持团队

如果上述步骤无法解决问题，请上报给 Bigtable 支持团队。

后续步骤

• 详细了解 Bigtable 性能。
• 请参阅 Bigtable 指标。
• 探索 Key Visualizer 中提供的指标。