使用指标诊断延迟时间
使用集合让一切井井有条根据您的偏好保存内容并对其进行分类。

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

延迟时间指标概览

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

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

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

根据每个请求的延迟时间，Spanner 将请求分组到不同的百分位中。您可以查看第 50 百分位和第 99 百分位延迟时间的延迟时间指标：

第 50 百分位延迟时间：所有请求中处理速度最快的 50% 的最长延迟时间（以秒为单位）。例如，如果第 50 百分位的延迟时间是 0.5 秒，表示有 50% 的请求可以在 0.5 秒内得到处理。

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

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

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

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

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

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

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

如果您的应用延迟时间比预期更长，并且 Cloud Spanner 的延迟时间指标也较长，可能有以下原因：

您的实例需要更多计算容量。如果您的实例没有足够的 CPU 资源，且其 CPU 利用率超过推荐的最大值，那么 Spanner 可能无法快速有效地处理您的请求。
您的某些查询导致高 CPU 利用率。如果您的查询没有使用能够提高效率的 Spanner 功能，例如查询参数和二级索引，或者查询包含大量联接或其他 CPU 密集型操作，则查询会占用很大一部分实例的 CPU 资源。

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

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

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

添加计算容量可提供更多 CPU 资源，并使 Spanner 能够处理更大的工作负载。
如果您发现有 CPU 密集型查询，请查看查询执行计划以了解查询速度慢的原因，然后按照 Spanner 的 SQL 最佳做法更新查询。

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