共用方式為

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

  • 發行項

本文可協助您調查行為 (的非預期變更，例如比平常慢的回應時間) 。 這些行為變更通常可透過監視 Azure 監視器中的記憶體計量來識別。 如需在 Azure 監視器中使用計量和記錄的一般資訊，請參閱下列文章：

監視效能

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

  • 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 服務。

用戶端延遲傳送要求的其中一個可能原因是可用的連線或線程數目有限。

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

  • 檢查記錄。 如果發生多次重試，您會看到具有相同用戶端要求標識碼的多個作業。

  • 檢查客戶端記錄。 詳細信息記錄會指出已發生重試。

  • 對程式代碼進行偵錯，並檢查與要求相關聯之 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 community 支援。 您也可以將產品意見反應提交給 Azure 意應見反社群。