排查 Azure 存储帐户中的性能问题

项目
11/20/2024

本文可帮助你调查行为意外更改（如比平时的响应时间慢）。通常可以通过监视 Azure Monitor 中的存储指标来识别这些行为更改。有关在 Azure Monitor 中使用指标和日志的一般信息，请参阅以下文章：

监视性能

若要监视存储服务的性能，可以使用以下指标：

SuccessE2ELatency 和 SuccessServerLatency 指标显示存储服务或 API 操作类型处理请求所需的平均时间。 SuccessE2ELatency 是端到端延迟的度量值，包括读取请求和发送响应所需的时间，以及处理请求所需的时间（因此，请求到达存储服务后，还包括网络延迟）。 SuccessServerLatency 只是处理时间的度量值，因此排除与与客户端通信相关的任何网络延迟。
Egress 和 Ingress 指标显示进出存储服务或通过特定 API 操作类型的数据总量（以字节为单位）。
Transactions 指标显示存储服务的 API 操作正在接收的请求总数。事务是存储服务接收的请求总数。

可以监视这些值中的任何意外更改。这些更改可能指示存在需要进一步调查的问题。

在Azure 门户中，可以添加警报规则，以便在此服务的任何性能指标低于或超出指定的阈值时通知你。

诊断性能问题

应用程序的性能可能是主观判定的，尤其是从用户角度来看，更是如此。因此，请务必设置可用于帮助确定是否可能存在性能问题的基线指标。从客户端应用程序角度来看，有许多因素可能会影响 Azure 存储服务的性能。这些因素可能会在存储服务、客户端或网络基础结构中运行。因此，必须制定策略来确定性能问题的来源。

在根据指标确定性能问题的可能原因的位置后，可以使用日志文件查找详细信息以便进一步诊断并排查该问题。

指标显示高 SuccessE2ELatency 和低 SuccessServerLatency

在某些情况下，你可能会发现 SuccessE2ELatency 高于 SuccessServerLatency。存储服务仅对成功的请求计算指标 SuccessE2ELatency。与 SuccessServerLatency 不同，它包括客户端发送数据以及从存储服务接收确认所需的时间。因此，SuccessE2ELatency 与 SuccessServerLatency 之间的差异可能是由于客户端应用程序响应速度缓慢或网络条件过慢。

注意

还可以在存储日志记录日志数据中查看单个存储操作的 E2ELatency 和 ServerLatency。

调查客户端的性能问题

客户端响应速度缓慢的可能原因包括具有有限的可用连接或线程，或者 CPU、内存或网络带宽等资源不足。可以通过将客户端代码修改为更高效（例如，使用对存储服务的异步调用），或使用具有更多核心和更多内存的大型虚拟机来解决该问题。

对于表和队列服务，Nagle 算法还可以与 SuccessServerLatency 相比导致 SuccessE2ELatency 高。有关详细信息，请参阅 Post Nagle 的算法对小型请求不友好。可以使用命名空间中的System.Net类在代码ServicePointManager中禁用 Nagle 算法。应在调用应用程序中的表或队列服务之前执行此操作，因为这样不会影响已打开的连接。以下示例来自 Application_Start 辅助角色中的方法：

var connectionString = Constants.connectionString;
QueueServiceClient queueServiceClient = new QueueServiceClient(connectionString);
ServicePoint queueServicePoint = ServicePointManager.FindServicePoint(queueServiceClient.Uri);
queueServicePoint.UseNagleAlgorithm = false;

应检查客户端日志以查看客户端应用程序提交的请求数，并检查客户端中与 .NET 相关的常规性能瓶颈，例如 CPU、.NET 垃圾回收、网络利用率或内存。作为排查 .NET 客户端应用程序问题的起点，请参阅调试、跟踪和分析。

调查网络延迟问题

通常，因网络导致的高端到端延迟是由暂时状况导致的。可以使用 Wireshark 等工具调查暂时性和持久性网络问题，例如丢弃的数据包。

指标显示低 SuccessE2ELatency 和低 SuccessServerLatency，但客户端遇到高延迟

在这种情况下，最可能的原因是到达存储服务的存储请求出现延迟。应调查来自客户端的请求未通过 Blob 服务的原因。

客户端延迟发送请求的一个可能原因是，可用连接数或可用线程数有限。

此外，请检查客户端是否正在执行多次重试，并调查原因（如果为）。要确定客户端是否正在执行多次重试，可以：

检查日志。如果发生了多次重试，则会看到具有相同客户端请求 ID 的多个操作。
检查客户端日志。详细日志记录会指示重试已发生过。
调试代码，并检查与请求关联的对象的属性 OperationContext 。如果重试了该操作，该 RequestResults 属性将包含多个唯一请求。此外，还可以检查每个请求的开始和结束时间。

如果客户端没有问题，则应调查潜在的网络问题，例如数据包丢失。可以使用工具（如 Wireshark）调查网络问题。

指标显示高 SuccessServerLatency

如果 blob 下载请求出现高 SuccessServerLatency，则应使用存储日志来了解对于同一 blob（或一组 blob）是否存在重复的请求。对于 Blob 上传请求，应调查客户端正在使用的块大小（例如，块小于 64 K 会导致开销，除非读取也小于 64 K 块），以及多个客户端正在并行将块上传到同一 Blob。还应检查每分钟指标，了解导致超过每秒可伸缩性目标的请求数峰值。

如果针对同一 blob 或 blob 集出现重复请求时，Blob 下载请求的 SuccessServerLatency 较高，请考虑使用 Azure 缓存或 Azure 内容分发网络（CDN）缓存这些 blob。对于上传请求，可以通过使用较大的数据块大小来提高吞吐量。对于表查询，也可以在执行相同的查询操作并且数据不会频繁更改的客户端上实施客户端缓存。

高 SuccessServerLatency 值也可能是设计欠佳的表或查询的症状，它会导致扫描操作或执行追加/前面预置反模式。

注意

可以从Microsoft Azure 存储性能和可伸缩性清单中找到全面的性能清单。

队列上的消息传递出现意外的延迟

如果在应用程序向队列添加消息的时间与从队列中读取消息的时间之间遇到延迟，请执行以下步骤来诊断问题：

验证应用程序是否成功将消息添加到队列。在成功之前，请检查应用程序是否未多次重试 AddMessage 该方法。
验证辅助角色在将消息添加到队列和从队列中读取消息的辅助角色之间没有时钟偏差。时钟倾斜使它看起来好像处理存在延迟。
检查从队列中读取该消息的辅助角色是否出现故障。如果队列客户端调用 GetMessage 该方法但无法响应确认，则消息将在队列中保持不可见，直到 invisibilityTimeout 期限到期。此时，该消息可供再次处理。
检查队列长度是否随着时间的推移不断增长。如果没有足够的辅助角色来处理其他辅助角色正在队列中放置的所有消息，则可能会出现这种情况。此外，请检查指标以查看删除请求是否失败，以及消息的取消排队计数，这可能表示重复尝试删除消息失败。
检查存储日志以查找在长于平常的时间段内具有高于预期的 E2ELatency 和 ServerLatency 值的任何队列操作。

另请参阅

联系我们寻求帮助

如果你有任何疑问或需要帮助，请创建支持请求或联系 Azure 社区支持。你还可以将产品反馈提交到 Azure 反馈社区。

通过