針對 Azure 記憶體帳戶中的效能進行疑難解答

發行項
11/20/2024

本文可協助您調查行為中的非預期變更（例如速度比平常慢的響應時間）。這些行為變更通常可藉由監視 Azure 監視器中的儲存體計量來識別。如需在 Azure 監視器中使用計量和記錄的一般資訊，請參閱下列文章：

監視效能

若要監視記憶體服務的效能，您可以使用下列計量：

SuccessE2ELatency 與 SuccessServerLatency 計量會顯示儲存體服務或 API 操作類型用來處理要求所需的平均時間。 SuccessE2ELatency 是端對端延遲的量值，包括讀取要求所需的時間，以及傳送回應，以及處理要求所需的時間（因此，一旦要求到達記憶體服務，它就會包含網路等待時間）。 SuccessServerLatency 只是處理時間的量值，因此排除與客戶端通訊相關的任何網路等待時間。
出口與輸入計量以位元組為單位，顯示進出儲存體服務或是透過特定 API 操作類型的資料總量。
交易計量顯示 API 操作所收到的儲存體服務要求總數。交易是記憶體服務接收的要求總數。

您可以監視這些值中的任何非預期變更。這些變更可能表示需要進一步調查的問題。

在 Azure 入口網站中，您可以新增警示規則，以在此服務的任何效能計量低於或超過您指定的閾值時通知您。

診斷效能問題

應用程式效能是很主觀的問題，尤其是從使用者觀點來看。因此，我們需要一套基準計量來協助您識別出現效能問題的位置。從用戶端應用程式觀點來看，許多因素都會影響 Azure 儲存體服務的效能。這些因素可能會在記憶體服務、用戶端或網路基礎結構中運作。因此，請務必制定策略來識別效能問題的來源。

當您從計量中找出了效能問題可能發生的位置時，就可以使用記錄檔來找出詳細資訊以便稍後進行診斷並疑難排解問題。

計量顯示高 SuccessE2ELatency 和低 SuccessServerLatency

在某些情況下，您可能會發現 SuccessE2ELatency 高於 SuccessServerLatency。儲存體服務只會計算成功要求的計量 SuccessE2ELatency，且會將用戶端用來傳送資料與接收儲存體服務認可所需的時間納入計算，不像 SuccessServerLatency。因此，SuccessE2ELatency 與 SuccessServerLatency 之間的差異可能是因為用戶端應用程式回應速度緩慢，或因為網路上的條件所致。

注意

您也可以在儲存體記錄資料中，檢視個別儲存體作業的 E2ELatency 與 ServerLatency。

調查用戶端效能問題

用戶端回應速度緩慢的可能原因包括有有限的可用連線或線程，或CPU、記憶體或網路頻寬等資源不足。您可以藉由將用戶端程式代碼修改為更有效率來解決此問題（例如，使用記憶體服務的異步呼叫），或使用具有更多核心和更多記憶體的較大虛擬機。

對於數據表和佇列服務，Nagle 演算法也會與 SuccessServerLatency 相比造成高 SuccessE2ELatency。如需詳細資訊，請參閱 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 服務。

用戶端延遲傳送要求的可能原因之一，是可用的連線或執行緒數量有限。

此外，請檢查用戶端是否正在執行多個重試，並調查其是否為。若要判斷用戶端是否正在執行多次的重試，您可以：

檢查記錄。如果發生多個重試，您會看到具有相同用戶端要求標識碼的多個作業。
檢查用戶端記錄。詳細資訊記錄會指出已發生的重試。
對程式代碼進行偵錯，並檢查與要求相關聯的物件屬性 OperationContext 。如果已重試作業，屬性 RequestResults 將會包含多個唯一要求。您也可以檢查每個要求的開始和結束時間。

如果用戶端裡沒有任何問題，請調查封包遺失之類的潛在網路問題。您可以使用 Wireshark 之類的工具來調查網路問題。

計量顯示高 SuccessServerLatency

當 Blob 下載要求出現高 SuccessServerLatency 時，請使用儲存體記錄功能來查看同一個 Blob (或是 Blob 集合) 是否重複出現要求。針對 Blob 上傳要求，您應該調查用戶端所使用的區塊大小（例如，區塊大小小於 64 K 可能會導致額外負荷，除非讀取也小於 64 K 區塊），以及多個用戶端平行將區塊上傳至相同的 Blob。您也應該檢查每分鐘計量中導致超過每秒延展性目標的要求數目尖峰。

如果您在相同 Blob 或一組 Blob 重複要求時看到 Blob 下載要求的 SuccessServerLatency，請考慮使用 Azure Cache 或 Azure 內容傳遞網路（CDN）快取這些 Blob。關於上傳要求，您可以使用較大的區塊大小來改善輸送量。關於資料表查詢，您也可以對執行相同查詢操作，且資料不會經常變動的用戶端，實作用戶端快取處理。

高 SuccessServerLatency 值同時也是資料表或查詢設計不良的徵兆，這種情況可能導致掃描作業，或是因為資料表或查詢遵循結尾附加/開頭附加的反模式而引起。

注意

您可以從 Microsoft Azure 儲存體效能和延展性檢查清單中找到完整的效能檢查清單。

佇列上的訊息在遞送期間出現非預期的延遲

如果您在應用程式將訊息新增至佇列，以及從佇列讀取時發生延遲，請採取下列步驟來診斷問題：

確認應用程式已成功將訊息新增至佇列。在成功之前，請檢查應用程式是否未重試 AddMessage 方法數次。
確認背景工作角色在將訊息新增至佇列和從佇列讀取訊息的背景工作角色之間沒有時鐘扭曲。時鐘扭曲會使它看起來像有延遲處理。
檢查負責從佇列讀取訊息的背景工作角色是否失敗。如果佇列用戶端呼叫 GetMessage 方法，但無法回應通知，訊息將會在佇列上保持不可見，直到 invisibilityTimeout 期間到期為止。此時，訊息才會再次可供處理。
檢查佇列長度在一段時間之後是否又增加了。如果您沒有足夠的背景工作角色可以處理其他背景工作角色在佇列中放置的所有訊息，就可能發生此情況。此外，請檢查計量，以查看刪除要求是否失敗，以及訊息的清除佇列計數，這可能表示重複嘗試刪除訊息。
檢查儲存體記錄中是否有任何佇列作業在超出慣常的期間內，產生超出預期的 E2ELatency 與 ServerLatency 值。

另請參閱

與我們連絡，以取得說明

如果您有問題或需要相關協助，請建立支援要求，或詢問 Azure community 支援。您也可以向 Azure 意見反應社群提交產品意見反應。

共用方式為