此页面由 Cloud Translation API 翻译。

使用指标诊断延迟时间

本页面介绍了 Spanner 提供的延迟时间指标。如果您的应用遇到延迟时间较长的情况，请使用这些指标帮助您诊断和解决问题。

延迟时间指标概览

Spanner 的延迟时间指标测量 Spanner 服务来处理请求。该指标捕获的是实际经过的时间，而不是 Spanner 使用的 CPU 时间。

这些延迟时间指标不包括在 Spanner 外部出现的延迟时间，例如网络延迟时间或应用层内的延迟时间。如需测量其他类型的延迟时间，您可以使用 Cloud Monitoring 通过自定义指标检测应用。

您可以在 Google Cloud 控制台和 Cloud Monitoring 控制台中查看延迟时间指标的图表。您可以查看包含读取和写入的组合延迟时间指标，也可以查看读取和写入的单独指标。

根据每个请求的延迟时间，Spanner 会将这些请求分组为百分位数。您可以查看第 50 百分位和第 99 百分位延迟时间的延迟时间指标：

第 50 百分位延迟时间：所有请求中处理速度最快的 50% 的最长延迟时间（以秒为单位）。例如，如果第 50 百分位的延迟时间为 0.5 秒，然后 Spanner 在 0.5 秒内处理了 50% 的请求。

该指标有时称为“延迟时间中间值”。
第 99 百分位延迟时间：所有请求中处理速度最快的 99% 的最长延迟时间（以秒为单位）。例如，如果第 99 百分位的延迟时间为 2 秒，则 Spanner 在不到 2 秒内处理了 99% 的请求。

如果实例在一段时间内处理的请求数量较少，那么此时间段内的第 50 百分位和第 99 百分位延迟时间对于判断该实例的整体性能而言意义不大。在此类情况下，极少数的离群值会大幅改变延迟时间指标。

例如，假设一个实例在一小时内处理 100 个请求。在这种情况下，该小时内此实例的第 99 百分位延迟时间是其处理最慢请求所花费的时间。针对单个请求进行延迟时间测量没有意义。

以下部分介绍了几个常见问题的诊断方法，这些问题可能导致应用遇到较长的端到端延迟时间。

如果您的应用延迟时间长于预期，但 Spanner 的延迟时间指标明显低于总延迟时间端到端延迟，那么应用代码中可能存在问题。如果您的应用存在导致某些代码路径变慢的性能问题，则每个请求总的端到端延迟时间可能会增加。

如需检查此问题，请对应用进行基准化分析，以找出比预期速度慢的代码路径。

您还可以注释掉与 Spanner 通信的代码，然后再次测量总延迟时间。如果总延迟时间没有明显变化，则 Spanner 不太可能是导致高延迟时间的原因。

如果您的应用延迟时间长于预期，并且 Spanner 延迟时间指标也很高，可能原因如下：

您的实例需要更多计算容量。如果您的实例没有足够的 CPU 资源，并且其 CPU 利用率超过建议的 max，则 Spanner 可能无法处理快速高效地响应您的请求
您的某些查询导致高 CPU 利用率。如果您的查询未充分利用可提高效率的 Spanner 功能（例如查询参数和次级索引），或者包含大量联接或其他 CPU 密集型操作，则这些查询可能会占用实例的大量 CPU 资源。

如需检查这些问题，请使用 Cloud Monitoring 控制台查找高 CPU 利用率和延迟时间较长之间的相关性。此外，请检查实例的查询统计信息，以便识别同一时间段内的 CPU 密集型查询。

如果您发现在某一时段，CPU 使用率较高，并且延迟时间较长，请采用以下方法解决此问题：

如果您没有发现许多 CPU 密集型查询，请为实例添加计算容量。

添加计算容量可提供更多 CPU 资源，并使 Spanner 能够处理更大的工作负载。
如果您发现了 CPU 密集型查询，请查看查询执行了解查询运行缓慢的原因，然后更新您的查询遵循最佳实践 Spanner。

您可能还需要检查数据库的架构设计并更新架构，以使查询更高效。