排查延迟时间问题

与任何数据库系统一样，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 百分比比例过大，与其他关联到该节点的平板电脑相比，热片使用的 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 中的最佳实践来缓解冷启动问题。

评估请求效率

使用查询统计信息评估请求效率。查询统计信息会显示所显示行数与返回行数之比，以及所显示单元数与返回单元数之比，从而指示查询效率。通过重新审视查询模式或架构设计来提高请求效率。如需了解详情，请参阅获取查询统计信息。

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

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

升级到 Bigtable 支持

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

后续步骤

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