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

项目
04/10/2024

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

监视性能

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

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

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

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

诊断性能问题

应用程序的性能可能是主观的，尤其是从用户的角度来看。因此，请务必提供基线指标，以帮助你确定可能存在性能问题的位置。从客户端应用程序的角度来看，许多因素可能会影响 Azure 存储服务的性能。这些因素可能在存储服务、客户端或网络基础结构中运行。因此，必须制定一个策略来识别性能问题的根源。

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

指标显示高 SuccessE2ELatency 和低 SuccessServerLatency

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

注意

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

调查客户端性能问题

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

对于表和队列服务，与 SuccessServerLatency 相比，Nagle 算法还会导致 SuccessE2ELatency 过高。有关详细信息，请参阅文章 Nagle 的算法对小型请求不友好。可以使用命名空间中的类在代码 ServicePointManager 中 System.Net 禁用 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 反馈社区提交产品反馈。