監視、診斷和疑難解答 Microsoft Azure 儲存體 (傳統)

本指南說明如何使用 Azure 儲存體分析、Azure 記憶體用戶端連結庫中的客戶端記錄等功能,以及其他第三方工具來識別、診斷及疑難解答 Azure 記憶體相關問題。

顯示用戶端應用程式與 Azure 記憶體服務之間資訊流程的圖表。

本指南主要供使用 Azure 記憶體服務的 線上服務 開發人員和負責管理這類 線上服務 的 IT 專業人員閱讀。 本指南的目標是:

  • 協助您維護 Azure 記憶體帳戶的健康情況和效能。
  • 為您提供必要的程式和工具,以協助您決定應用程式中的問題是否與 Azure 記憶體相關。
  • 為您提供可採取動作的指引,以解決與 Azure 記憶體相關的問題。

注意事項

本文是以使用 儲存體分析 計量和記錄為基礎,稱為傳統計量和記錄。 建議您在 Azure 監視器中使用 Azure 記憶體計量和記錄,而不是 儲存體分析 記錄。 若要深入瞭解,請參閱下列任何文章:

概觀

在雲端環境中裝載的分散式應用程式中診斷和疑難解答問題,可能會比傳統環境更複雜。 應用程式可以部署在 PaaS 或 IaaS 基礎結構、內部部署、行動裝置上,或這些環境的某些組合中。 一般而言,應用程式的網路流量可能會周遊公用和專用網,而且除了關係資料庫和檔資料庫等其他數據存放區之外,您的應用程式也可以使用多個記憶體技術,例如 Microsoft Azure 儲存體 數據表、Blob、佇列或檔案。

若要成功管理這類應用程式,您應該主動監視它們,並瞭解如何診斷這些應用程式及其相依技術的所有層面並進行疑難解答。 身為 Azure 記憶體服務的使用者,您應該持續監視應用程式所使用的記憶體服務,以取得任何非預期的行為變更 (例如) 比平常慢的回應時間,並使用記錄來收集更詳細的數據,並深入分析問題。 您從監視和記錄取得的診斷資訊可協助您判斷應用程式遇到問題的根本原因。 然後,您可以針對問題進行疑難解答,並判斷適當的補救步驟。 Azure 記憶體是核心 Azure 服務,也是客戶部署至 Azure 基礎結構之大多數解決方案的重要部分。 Azure 記憶體包含的功能可簡化雲端式應用程式中記憶體問題的監視、診斷和疑難解答。

本指南的組織方式

監視記憶體服務一節說明如何使用 Azure 儲存體分析 計量 (記憶體計量) 來監視 Azure 記憶體服務的健康情況和效能。

診斷記憶體問題一節說明如何使用 Azure 儲存體分析 記錄 (記憶體記錄) 來診斷問題。 它也會說明如何使用其中一個用戶端連結庫中的功能來啟用客戶端記錄,例如適用於 .NET 的記憶體用戶端連結庫或適用於 Java 的 Azure SDK。

端對端追蹤一節說明如何將各種記錄檔和計量數據中包含的資訊相互關聯。

難解答指引 一節提供您可能會遇到的一些常見記憶體相關問題的疑難解答指引。

[附錄] 區段包含使用Wireshark和Netmon等其他工具來分析網路封包數據的相關信息,以及用來分析 HTTP/HTTPS 訊息的 Fiddler。

監視您的記憶體服務

如果您熟悉 Windows 效能監視,您可以將記憶體計量視為相當於 Windows 效能監視器 計數器的 Azure 記憶體。 在記憶體計量中,您會在 Windows 效能監視器 術語) 中找到一組完整的計量 (計數器,例如服務可用性、服務要求總數,或成功要求服務的百分比。 如需可用計量的完整清單,請參閱 儲存體分析 計量數據表架構。 您可以指定是否要讓記憶體服務每小時或每分鐘收集和匯總計量。 如需如何啟用計量及監視記憶體帳戶的詳細資訊,請參閱 啟用記憶體計量和檢視計量數據

您可以選擇要在 Azure 入口網站 中顯示的每小時計量,並設定在每小時計量超過特定閾值時,透過電子郵件通知系統管理員的規則。 如需詳細資訊,請參閱 接收警示通知

建議您檢閱 適用於記憶體的 Azure 監視器 (預覽) 。 這是 Azure 監視器的一項功能,可藉由提供 Azure 記憶體服務效能、容量和可用性的統一檢視,提供 Azure 記憶體帳戶的完整監視。 您不需要啟用或設定任何專案,而且可以立即從預先定義的互動式圖表和其他包含的視覺效果檢視這些計量。

記憶體服務會嘗試收集計量,但可能不會記錄每個記憶體作業。

在 Azure 入口網站 中,您可以檢視計量,例如可用性、要求總數,以及記憶體帳戶的平均延遲數位。 如果可用性低於特定層級,也會設定通知規則來警示系統管理員。 從檢視此數據,其中一個可能的調查領域是數據表服務成功百分比低於 100% (如需詳細資訊,請參閱 度量顯示低 PercentSuccess 或分析記錄專案具有交易狀態為 ClientOtherErrors 的作業 區段) 。

您應該持續監視您的 Azure 應用程式,以確保其狀況良好且如預期般執行:

  • 為應用程式建立一些基準計量,可讓您比較目前的數據,並識別 Azure 記憶體和應用程式行為的任何重大變更。 在許多情況下,基準計量的值會是應用程式特定值,而且您應該在測試應用程式效能時加以建立。
  • 記錄分鐘計量,並使用它們主動監視非預期的錯誤和異常,例如錯誤計數或要求率的尖峰。
  • 記錄每小時計量,並使用它們來監視平均值,例如平均錯誤計數和要求率。
  • 使用診斷工具調查潛在問題,如 稍後診斷記憶體問題 一節中所述。

下圖中的圖表說明每小時計量的平均值如何隱藏活動尖峰。 每小時計量會顯示穩定的要求率,而分鐘度量則會顯示實際發生的波動。

顯示每小時計量的平均值如何隱藏活動尖峰的圖表。

本節的其餘部分將說明您應該監視的計量和原因。

監視服務健康情況

您可以使用 Azure 入口網站 來檢視全球所有 Azure 區域中記憶體服務 (和其他 Azure 服務) 的健康情況。 監視可讓您立即查看控制項外部的問題是否會影響您用於應用程式之區域中的記憶體服務。

Azure 入口網站 也可以提供影響各種 Azure 服務的事件通知。

注意事項

此資訊先前可在 Azure 服務儀錶板上取得,以及歷程記錄數據。 如需適用於 Azure DevOps 的 Application Insights 詳細資訊,請參閱 附錄 5:使用適用於 Azure DevOps 的 Application Insights 進行監視

監視容量

記憶體計量只會儲存 Blob 服務的容量計量,因為 Blob 在寫入時通常占儲存數據 (的最大比例,所以無法使用記憶體計量來監視數據表和佇列) 的容量。 如果您已啟用 Blob 服務的 $MetricsCapacityBlob 監視,您可以在資料表中找到此資料。 記憶體計量每天記錄此資料一次,您可以使用 的 RowKey 值來判斷數據列是否包含與使用者數據相關聯的實體 (值 data) 或分析數據 (值 analytics) 。 每個預存實體都包含 (以位元組) Capacity 測量的記憶體數量,以及目前 () 和 Blob 數目的 ContainerCount 資訊, (ObjectCount) 在記憶體帳戶中使用。 如需儲存在數據表中$MetricsCapacityBlob之容量計量的詳細資訊,請參閱 儲存體分析 計量數據表架構

注意事項

您應該監視這些值,以取得即將達到記憶體帳戶容量限制的早期警告。 在 Azure 入口網站 中,您可以新增警示規則,以在匯總記憶體使用量超過或低於您指定的閾值時通知您。

若要估計各種記憶體物件的大小,例如 Blob,請參閱部落格文章 瞭解 Azure 記憶體計費 – 帶寬、交易和容量

監視可用性

您應該監視記憶體帳戶中記憶體服務的可用性,方法是監視每小時或分鐘度量資料表中 資料行中的Availability值 , 、$MetricsHourPrimaryTransactionsTable$MetricsHourPrimaryTransactionsBlob 、 、 、 $MetricsHourPrimaryTransactionsQueue$MetricsMinutePrimaryTransactionsBlob$MetricsMinutePrimaryTransactionsTable、 、 、 $MetricsMinutePrimaryTransactionsQueue$MetricsCapacityBlob 數據 Availability 行包含百分比值,指出服務的可用性或數據列所代表的 API 作業 (RowKey 顯示資料列是否包含整個服務或特定 API 作業的計量) 。

任何小於 100% 的值都表示某些記憶體要求失敗。 您可以檢查計量數據中顯示不同錯誤類型要求數目的其他數據行,例如 ServerTimeoutError,以查看失敗的原因。 您應該會因為暫時性伺服器逾時等原因而預期 Availability 會暫時低於 100%,而服務會將分割區移至更好的負載平衡要求;用戶端應用程式中的重試邏輯應該會處理這類間歇性狀況。 儲存體分析 記錄作業和狀態消息一文會列出記憶體計量在其Availability計算中包含的交易類型。

Azure 入口網站 中,您可以新增警示規則,以在服務低於您指定的閾值時Availability通知您。

本指南 的疑難解答指引 一節說明一些與可用性相關的常見記憶體服務問題。

監視效能

若要監視記憶體服務的效能,您可以使用每小時和分鐘度量數據表中的下列計量。

  • AverageServerLatency 資料列中的AverageE2ELatency值會顯示記憶體服務或 API 作業類型處理要求的平均時間。 AverageE2ELatency 是端對端延遲的量值,包括讀取要求和傳送回應所花費的時間,以及處理要求所花費的時間 (因此,一旦要求到達記憶體服務) ,就會包含網路等待時間; AverageServerLatency 只是處理時間的量值,因此會排除與客戶端通訊相關的任何網路等待時間。 請參閱本指南稍後 的計量顯示高 AverageE2ELatency 和低 AverageServerLatency 一節,以瞭解這兩個值之間可能有顯著差異的原因。
  • TotalEgress 資料行中的TotalIngress值會顯示傳入和傳出記憶體服務或透過特定 API 作業類型的數據總量,以位元組為單位。
  • 數據列中的 TotalRequests 值會顯示 API 作業的記憶體服務收到的要求總數。 TotalRequests 是記憶體服務收到的要求總數。

一般而言,您會監視這些值中的任何非預期變更,因為這表示您有需要調查的問題。

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

本指南 的疑難解答指引 一節說明一些與效能相關的常見記憶體服務問題。

診斷記憶體問題

有幾種方式可讓您知道應用程式中的問題,包括:

  • 導致應用程式當機或停止運作的重大失敗。
  • 您所監視計量中基準值的重大變更,如上一節 監視記憶體服務中所述。
  • 應用程式用戶回報某些特定作業未如預期般完成,或某些功能無法運作。
  • 在您的應用程式中產生的錯誤,這些錯誤會出現在記錄檔中,或透過一些其他通知方法。

一般而言,與 Azure 記憶體服務相關的問題會分成四大類別之一:

  • 您的應用程式有效能問題,可能是由您的用戶回報,或是效能計量變更所顯示。
  • 一或多個區域中的 Azure 記憶體基礎結構有問題。
  • 您的應用程式遇到錯誤,可能是由您的用戶報告,或由您監視的其中一個錯誤計數計量增加而顯示。
  • 在開發和測試期間,您可能會使用本機記憶體模擬器;您可能會遇到一些與記憶體模擬器使用方式特別相關的問題。

下列各節概述您應該遵循的步驟,以針對這四個類別中的每一個問題進行診斷和疑難解答。 The Troubleshooting guidance section later in this guide provides more detail for some common issues you may encounter.

服務健康情況 問題

服務健康情況 問題通常不在您的控制範圍之外。 此 Azure 入口網站 提供有關 Azure 服務任何持續性問題的資訊,包括記憶體服務。 如果您在建立記憶體帳戶時選擇 Read-Access Geo-Redundant 記憶體,則如果您的數據在主要位置變成無法使用,則應用程式可以暫時切換至次要位置中的唯讀複本。 若要從次要復本讀取,您的應用程式必須能夠在使用主要和次要儲存位置之間切換,而且能夠在功能降低模式中使用唯讀數據。 Azure 記憶體用戶端連結庫可讓您定義重試原則,以在主要記憶體讀取失敗時從次要記憶體讀取。 您的應用程式也必須注意,次要位置中的數據最終是一致的。 如需詳細資訊,請參閱部落格文章 Azure 記憶體備援選項和讀取許可權異地備援記憶體

效能問題

應用程式的效能可以是主體性的,特別是從用戶的觀點來看。 因此,請務必提供基準計量,以協助您找出效能問題可能發生的位置。 從用戶端應用程式的觀點來看,許多因素可能會影響 Azure 記憶體服務的效能。 這些因素可能會在記憶體服務、用戶端或網路基礎結構中運作;因此,請務必使用策略來識別效能問題的來源。

從計量識別出效能問題原因的可能位置之後,您可以接著使用記錄檔來尋找詳細資訊,進一步診斷問題並進行疑難解答。

本指南稍後 的疑難解答指引 一節提供您可能會遇到的一些常見效能相關問題的詳細資訊。

診斷錯誤

應用程式的使用者可能會通知您用戶端應用程式所報告的錯誤。 記憶體計量也會記錄記憶體服務中不同錯誤類型的計數,例如 NetworkError、ClientTimeoutError 或 AuthorizationError。 雖然記憶體計量只會記錄不同錯誤類型的計數,但您可以檢查伺服器端、用戶端和網路記錄,以取得個別要求的詳細數據。 通常,記憶體服務所傳回的 HTTP 狀態代碼會指出要求失敗的原因。

注意事項

請記住,您應該會看到一些間歇性錯誤:例如,由於暫時性網路狀況或應用程式錯誤所造成的錯誤。

下列資源有助於瞭解記憶體相關的狀態和錯誤碼:

記憶體模擬器問題

Azure SDK 包含您可以在開發工作站上執行的記憶體模擬器。 此模擬器會模擬 Azure 記憶體服務的大部分行為,而且在開發和測試期間很有用,可讓您執行使用 Azure 記憶體服務的應用程式,而不需要 Azure 訂用帳戶和 Azure 記憶體帳戶。

本指南 的疑難解答指引 一節說明使用記憶體模擬器時遇到的一些常見問題。

記憶體記錄工具

記憶體記錄可在您的 Azure 記憶體帳戶中提供記憶體要求的伺服器端記錄。 如需如何啟用伺服器端記錄和存取記錄數據的詳細資訊,請參閱 啟用記憶體記錄和存取記錄數據

適用於 .NET 的記憶體用戶端連結庫可讓您收集與應用程式所執行之記憶體作業相關的客戶端記錄數據。 如需詳細資訊,請參閱使用 .NET 記憶體客戶端連結庫進行客戶端記錄

注意事項

在某些情況下 (例如 SAS 授權失敗) ,使用者可能會回報錯誤,而您在伺服器端記憶體記錄中找不到任何要求數據。 您可以使用記憶體用戶端連結庫的記錄功能來調查問題的原因是否在用戶端上,或使用網路監視工具來調查網路。

使用網路記錄工具

您可以擷取客戶端與伺服器之間的流量,以提供客戶端和伺服器正在交換之數據以及基礎網路條件的詳細資訊。 實用的網路記錄工具包括:

在許多情況下,來自記憶體記錄和記憶體用戶端連結庫的記錄數據就足以診斷問題,但在某些情況下,您可能需要這些網路記錄工具可以提供的更詳細資訊。 例如,使用 Fiddler 檢視 HTTP 和 HTTPS 訊息可讓您檢視傳送至記憶體服務的標頭和承載數據,這可讓您檢查用戶端應用程式重試記憶體作業的方式。 Wireshark 之類的通訊協定分析器會在封包層級運作,讓您能夠檢視 TCP 數據,這可讓您針對遺失的封包和聯機問題進行疑難解答。

端對端追蹤

使用各種記錄檔進行端對端追蹤是調查潛在問題的實用技術。 您可以使用計量數據中的日期/時間資訊,指出開始在記錄檔中尋找詳細資訊的位置,以協助您針對問題進行疑難解答。

將記錄數據相互關聯

從用戶端應用程式、網路追蹤和伺服器端記憶體記錄檢視記錄時,必須能夠讓不同記錄檔的要求相互關聯。 記錄檔包含許多不同的欄位,這些字段對於相互關聯標識元很有用。 用戶端要求標識碼是最有用的字段,可用來將不同記錄中的專案相互關聯。 不過,有時候使用伺服器要求標識碼或時間戳可能很有用。 下列各節提供這些選項的更多詳細數據。

用戶端要求標識碼

記憶體客戶端連結庫會自動為每個要求產生唯一的用戶端要求標識碼。

  • 在記憶體用戶端連結庫所建立的用戶端記錄檔中 Client Request ID ,用戶端要求標識碼會出現在與要求相關的每個記錄專案欄位中。
  • 在 Fiddler 所擷取的網路追蹤中,用戶端要求標識碼會以 HTTP 標頭值顯示在要求訊息 x-ms-client-request-id 中。
  • 在伺服器端記憶體記錄檔中,用戶端要求標識碼會出現在 [用戶端要求標識符] 資料行中。

注意事項

多個要求可能會共用相同的用戶端要求標識符,因為用戶端可以指派此值 (雖然記憶體用戶端連結庫會自動指派新值) 。 當用戶端重試時,所有嘗試都會共用相同的用戶端要求標識碼。 如果是從用戶端傳送的批次,批次會有單一用戶端要求標識符。

伺服器要求標識碼

記憶體服務會自動產生伺服器要求標識碼。

  • 在伺服器端記憶體記錄檔中,伺服器要求標識碼會出現在數據行中 Request ID header
  • 在 Fiddler 所擷取的網路追蹤中,伺服器要求標識碼會在回應消息中顯示為 x-ms-request-id HTTP 標頭值。
  • 在記憶體用戶端連結庫所建立的用戶端記錄檔中 Operation Text ,伺服器要求標識碼會出現在顯示伺服器回應詳細數據的記錄項目數據行中。

注意事項

記憶體服務一律會將唯一的伺服器要求標識符指派給它收到的每個要求,因此每次從用戶端重試嘗試和批次中包含的每個作業都有唯一的伺服器要求標識符。

下列程式代碼範例示範如何使用自定義用戶端要求標識碼。

var connectionString = Constants.connectionString;

BlobServiceClient blobServiceClient = new BlobServiceClient(connectionString);

BlobContainerClient blobContainerClient = blobServiceClient.GetBlobContainerClient("demcontainer");

BlobClient blobClient = blobContainerClient.GetBlobClient("testImage.jpg");

string clientRequestID = String.Format("{0} {1} {2} {3}", HOSTNAME, APPNAME, USERID, Guid.NewGuid().ToString());

using (HttpPipeline.CreateClientRequestIdScope(clientRequestID))
{
    BlobDownloadInfo download = blobClient.Download();

    using (FileStream downloadFileStream = File.OpenWrite("C:\\testImage.jpg"))
    {
        download.Content.CopyTo(downloadFileStream);
        downloadFileStream.Close();
    }
}

時間 戳

您也可以使用時間戳來尋找相關的記錄專案,但請小心客戶端與伺服器之間可能存在的任何時鐘誤差。 搜尋 加減 15 分鐘,根據用戶端上的時間戳比對伺服器端專案。 請記住,包含計量之 Blob 的 Blob 元數據會指出儲存在 Blob 中計量的時間範圍。 如果您在同一分鐘或小時有許多計量 Blob,這個時間範圍就很有用。

疑難排解指引

本節將協助您診斷應用程式在使用 Azure 記憶體服務時可能會遇到的一些常見問題並進行疑難解答。 使用下列清單來找出與您特定問題相關的資訊。

針對判定樹進行疑難解答


您的問題與其中一個記憶體服務的效能有關嗎?


您的問題與其中一個記憶體服務的可用性有關嗎?


您的用戶端應用程式是否收到來自記憶體服務的 HTTP 4XX (,例如 404) 回應?


度量顯示低 PercentSuccess 或分析記錄專案具有交易狀態為 ClientOtherErrors 的作業


容量計量顯示記憶體容量使用量意外增加


您的問題起因於使用記憶體模擬器進行開發或測試


您在安裝適用於 .NET 的 Azure SDK 時遇到問題


您對記憶體服務有不同的問題


計量顯示高 AverageE2ELatency 和低 AverageServerLatency

下圖顯示下列 Azure 入口網站 監視工具的範例,其中 AverageE2ELatency 明顯高於 AverageServerLatency

Azure 入口網站的圖例,其中顯示 AverageE2ELatency 明顯高於 AverageServerLatency 的範例。

記憶體服務只會計算成功要求的度量 AverageE2ELatency ,不同 於 AverageServerLatency,包含用戶端從記憶體服務傳送數據和接收通知所花費的時間。 因此, AverageE2ELatencyAverageServerLatency 之間的差異可能是因為用戶端應用程式回應速度緩慢或網路上的條件所造成。

注意事項

您也可以在記憶體記錄記錄數據中檢視個別記憶體作業的 E2ELatencyServerLatency

調查用戶端效能問題

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

就數據表和佇列服務而言,相較於 AverageServerLatency,Nagle 演算法也可能導致高 AverageE2ELatency。 如需詳細資訊,請參閱 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之類的工具來調查暫時性和持續性網路問題,例如已卸除的封包。

如需使用Wireshark對網路問題進行疑難解答的詳細資訊,請參閱 附錄 2:使用Wireshark擷取網路流量

計量顯示低 AverageE2ELatency 和低 AverageServerLatency,但用戶端遇到高延遲

在此案例中,最可能的原因是記憶體要求到達記憶體服務時發生延遲。 您應該調查為什麼來自用戶端的要求未通過 Blob 服務。

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

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

  • 檢查 儲存體分析記錄。 如果發生多次重試,您會看到具有相同用戶端要求標識碼但具有不同伺服器要求標識碼的多個作業。
  • 檢查客戶端記錄。 詳細信息記錄會指出已發生重試。
  • 對程式代碼進行偵錯,並檢查與要求相關聯之 OperationContext 對象的屬性。 如果已重試作業,屬性 RequestResults 將會包含多個唯一的伺服器要求標識符。 您也可以檢查每個要求的開始和結束時間。 如需詳細資訊,請參閱 伺服器要求標識符一節中的程式代碼範例。

如果客戶端中沒有任何問題,您應該調查潛在的網路問題,例如封包遺失。 您可以使用Wireshark之類的工具來調查網路問題。

如需使用Wireshark對網路問題進行疑難解答的詳細資訊,請參閱 附錄 2:使用Wireshark擷取網路流量

度量顯示高 AverageServerLatency

如果 Blob 下載要求的 AverageServerLatency 很高,您應該使用記憶體記錄來查看相同 Blob (或一組 Blob 的重複要求) 。 針對 Blob 上傳要求,您應該調查用戶端所使用的區塊大小 (例如,大小小於 64 K 的區塊可能會產生額外負荷,除非讀取也位於小於 64 K 的區塊) ,以及是否有多個用戶端平行上傳區塊至相同的 Blob。 您也應該檢查每分鐘度量,以了解導致超過每秒延展性目標的要求數目尖峰。 如需詳細資訊, 請參閱計量顯示 PercentTimeoutError 的增加

如果您在相同 Blob 或一組 Blob 的重複要求時看到 Blob 下載要求的高 AverageServerLatency ,則請考慮使用 Azure 快取或 Azure 內容傳遞網路 (CDN) 來快取這些 Blob。 針對上傳要求,您可以使用較大的區塊大小來改善輸送量。 針對數據表的查詢,也可以在執行相同查詢作業的用戶端上實作用戶端快取,且數據不會經常變更。

AverageServerLatency 值也可能是設計不良數據表或查詢的徵兆,這些數據表或查詢會導致掃描作業或遵循附加/預先附加的反模式。 如需詳細資訊, 請參閱計量顯示 PercentThrottlingError 的增加

注意事項

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

您在佇列上遇到非預期的訊息傳遞延遲

如果您在應用程式將訊息新增至佇列的時間與從佇列讀取的時間之間遇到延遲,請採取下列步驟來診斷問題:

  • 確認應用程式已成功將訊息新增至佇列。 請先檢查應用程式未重試 AddMessage 方法數次,再成功。 儲存體客戶端連結庫記錄會顯示記憶體作業的任何重複重試。
  • 確認將訊息新增至佇列的背景工作角色與從佇列讀取訊息的背景工作角色之間沒有時鐘誤差。 時鐘誤差會讓它顯示為處理有延遲。
  • 檢查從佇列讀取訊息的背景工作角色是否失敗。 如果佇列用戶端呼叫 方法 GetMessage ,但無法回應通知,則在期間到期之前 invisibilityTimeout ,佇列上的訊息將維持不可見狀態。 此時,訊息會變成可供再次處理。
  • 檢查佇列長度是否隨著時間增加。 如果您沒有足夠的背景工作角色可用來處理其他背景工作角色放在佇列中的所有訊息,就可能發生這種情況。 此外,請檢查計量以查看刪除要求是否失敗,以及訊息的清除佇列計數,這可能表示重複嘗試刪除訊息失敗。
  • 檢查記憶體記錄記錄中是否有任何佇列作業的 E2ELatencyServerLatency 值高於預期,且時間比平常長。

計量顯示 PercentThrottlingError 增加

當您超過記憶體服務的延展性目標時,就會發生節流錯誤。 記憶體服務會進行節流,以確保沒有單一用戶端或租使用者可以犧牲其他用戶端或租使用者來使用服務。 如需詳細資訊,請參閱 標準記憶體帳戶的延展性和效能目標 ,以取得記憶體帳戶的延展性目標,以及記憶體帳戶內數據分割的效能目標。

如果 PercentThrottlingError 計量顯示因節流錯誤而失敗的要求百分比增加,您需要調查下列兩種案例之一:

PercentThrottlingError 的增加通常會在記憶體要求數目增加或您一開始對應用程式進行負載測試時同時發生。 這也可能會在用戶端中顯示為來自記憶體作業的「503 伺服器忙碌」或「500 作業逾時」HTTP 狀態消息。

PercentThrottlingError 的暫時性增加

如果您看到 PercentThrottlingError 值的尖峰與應用程式的高活動期間一致,您可以針對用戶端中的重試實作指數 (非線性) 輪詢策略。 備份重試可減少分割區的立即負載,並協助您的應用程式平滑流量尖峰。 如需如何使用記憶體用戶端連結庫實作重試原則的詳細資訊,請參閱 Microsoft.Azure.Storage.RetryPolicies 命名空間

注意事項

您也可能會看到 PercentThrottlingError 值的尖峰,與應用程式的高活動期間不一致。 最可能的原因是記憶體服務移動分割區以改善負載平衡。

PercentThrottlingError 的永久增加

如果您在交易量永久增加之後,或在應用程式上執行初始負載測試時,看到 PercentThrottlingError 的持續高值,則您必須評估應用程式使用記憶體分割區的方式,以及其是否接近記憶體帳戶的延展性目標。 例如,如果您在佇列上看到節流錯誤, (算為單一分割區) ,則請考慮使用額外的佇列將交易分散到多個分割區。 如果您在數據表上看到節流錯誤,您必須考慮使用不同的數據分割配置,藉由使用更廣泛的分割區索引鍵值,將交易分散到多個分割區。 此問題的一個常見原因是預先附加/附加反模式,其中您選取日期做為分割區索引鍵,然後特定日期的所有數據都會寫入一個分割區:在負載下,這可能會導致寫入瓶頸。 請考慮不同的數據分割設計,或評估使用 Blob 記憶體是否可能是更好的解決方案。 此外,請檢查是否因為流量尖峰而發生節流,並調查平滑要求模式的方式。

如果您將交易分散到多個分割區,您仍然必須留意為記憶體帳戶設定的延展性限制。 例如,如果您使用十個佇列,每個佇列每秒最多處理 2,000 1 KB 訊息,則記憶體帳戶的整體限制為每秒 20,000 則訊息。 如果您需要每秒處理超過 20,000 個實體,請考慮使用多個記憶體帳戶。 您也應該記住,當記憶體服務對客戶端進行節流時,要求和實體的大小會受到影響。 如果您有較大的要求和實體,可能會更快地進行節流。

無效率的查詢設計也可能導致您達到數據表分割區的延展性限制。 例如,具有篩選條件的查詢只會選取分割區中百分之一的實體,但會掃描分割區中所有實體的查詢,就必須存取每個實體。 每個實體讀取都會會計入該分割區中的交易總數;因此,您可以輕鬆地觸達延展性目標。

注意事項

您的效能測試應該會顯示應用程式中任何沒有效率的查詢設計。

計量顯示 PercentTimeoutError 增加

您的計量顯示其中一個記憶體服務的 PercentTimeoutError 增加。 同時,用戶端會收到來自記憶體作業的大量「500 作業逾時」HTTP 狀態消息。

注意事項

當記憶體服務將分割區移至新伺服器以平衡要求時,您可能會看到暫時的逾時錯誤。

PercentTimeoutError 計量是下列計量的匯總:ClientTimeoutErrorAnonymousClientTimeoutErrorSASClientTimeoutErrorServerTimeoutErrorAnonymousServerTimeoutErrorSASServerTimeoutError

伺服器逾時是由伺服器上的錯誤所造成。 發生用戶端逾時是因為伺服器上的作業已超過用戶端所指定的逾時;例如,使用記憶體用戶端連結庫的用戶端可以使用 ServerTimeout 類別的 屬性來設定作業的 QueueRequestOptions 逾時。

伺服器逾時表示記憶體服務有問題,需要進一步調查。 您可以使用計量來查看您是否達到服務的延展性限制,並識別可能造成此問題的任何流量尖峰。 如果問題是間歇性的,可能是因為服務中的負載平衡活動。 如果問題持續發生,而且不是由您的應用程式達到服務的延展性限制所造成,您應該提出支持問題。 針對用戶端逾時,您必須決定逾時是否設定為用戶端中的適當值,並變更客戶端中設定的逾時值,或調查如何改善記憶體服務中作業的效能,例如優化數據表查詢或減少訊息大小。

計量顯示 PercentNetworkError 增加

您的計量顯示其中一個記憶體服務的 PercentNetworkError 增加。 PercentNetworkError 計量是下列計量的匯總:NetworkErrorAnonymousNetworkErrorSASNetworkError。 當記憶體服務在用戶端提出記憶體要求時偵測到網路錯誤時,就會發生這些錯誤。

此錯誤最常見的原因是客戶端在記憶體服務逾時到期之前中斷連線。 調查用戶端中的程式代碼,以瞭解用戶端與記憶體服務中斷連線的原因和時機。 您也可以使用Wireshark或 Tcping 來調查來自客戶端的網路連線問題。 這些工具會在 附錄中說明。

用戶端收到 HTTP 403 (禁止) 訊息

如果您的用戶端應用程式擲回 HTTP 403 (禁止) 錯誤,可能是因為用戶端在傳送記憶體要求 (時使用過期的共用存取簽章 (SAS) ,但其他可能的原因包括時鐘誤差、密鑰無效,以及) 空白標頭。 如果造成 SAS 金鑰過期,您就不會在伺服器端記憶體記錄記錄資料中看到任何專案。 下表顯示記憶體用戶端連結庫所產生之客戶端記錄檔的範例,說明發生此問題:

來源 冗長 冗長 用戶端要求標識碼 作業文字
Microsoft.Azure.Storage Information 3 85d077ab-... Starting operation with location Primary per location mode PrimaryOnly.
Microsoft.Azure.Storage Information 3 85d077ab -... Starting synchronous request to https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Synchronous_and_Asynchronous_Requests#Synchronous_request.
Microsoft.Azure.Storage Information 3 85d077ab -... Waiting for response.
Microsoft.Azure.Storage 警告 2 85d077ab -... Exception thrown while waiting for response: The remote server returned an error: (403) Forbidden.
Microsoft.Azure.Storage Information 3 85d077ab -... Response received. Status code = 403, Request ID = <Request ID>, Content-MD5 = , ETag = .
Microsoft.Azure.Storage 警告 2 85d077ab -... Exception thrown during the operation: The remote server returned an error: (403) Forbidden..
Microsoft.Azure.Storage Information 3 85d077ab -... Checking if the operation should be retried. Retry count = 0, HTTP status code = 403, Exception = The remote server returned an error: (403) Forbidden..
Microsoft.Azure.Storage Information 3 85d077ab -... The next location has been set to Primary, based on the location mode.
Microsoft.Azure.Storage 錯誤 1 85d077ab -... Retry policy did not allow for a retry. Failing with The remote server returned an error: (403) Forbidden.

在此案例中,您應該在用戶端將令牌傳送至伺服器之前,調查 SAS 令牌到期的原因:

  • 一般而言,您不應該在建立 SAS 以讓用戶端立即使用時設定開始時間。 如果使用目前時間產生SAS的主機與記憶體服務之間有小的時鐘差異,則記憶體服務可能會收到尚未有效的SAS。
  • 請勿在 SAS 上設定非常短的到期時間。 同樣地,產生SAS的主機與記憶體服務之間的小時鐘差異,可能會導致SAS似乎比預期的更早到期。
  • 例如 sv,SAS 金鑰 (中的版本參數 =2015-04-05) 符合您使用的記憶體用戶端連結庫版本嗎? 建議您一律使用最新版的 記憶體用戶端連結庫
  • 如果您重新產生記憶體存取金鑰,任何現有的 SAS 令牌可能會失效。 如果您產生 SAS 令牌,且用戶端應用程式快取的到期時間很長,就可能會發生此問題。

如果您使用記憶體用戶端連結庫來產生SAS令牌,則可以輕鬆地建置有效的令牌。 不過,如果您使用記憶體 REST API 並手動建構 SAS 令牌,請參閱使用共用存 取簽章委派存取權。

用戶端收到 HTTP 404 (找不到) 訊息

如果用戶端應用程式從伺服器收到 HTTP 404 (找不到) 訊息,這表示客戶端嘗試使用 (的物件,例如實體、數據表、Blob、容器或佇列) 不存在於記憶體服務中。 有一些可能的原因,例如:

用戶端或其他進程先前已刪除物件

在客戶端嘗試讀取、更新或刪除記憶體服務中的數據的情況下,通常很容易在伺服器端記錄中識別先前從記憶體服務刪除有問題的物件的作業。 記錄數據通常會顯示另一個用戶或進程已刪除物件。 在伺服器端記憶體記錄檔中,當用戶端刪除物件時,會顯示 operation-type 和 requested-object-key 數據行。

在用戶端嘗試插入物件的案例中,如果用戶端正在建立新物件,可能無法立即看出這會導致 HTTP 404 (找不到) 回應的原因。 不過,如果用戶端正在建立 Blob,它必須能夠找到 Blob 容器。 如果用戶端正在建立訊息,它必須能夠找到佇列。 如果用戶端正在新增數據列,它必須能夠找到數據表。

您可以使用記憶體用戶端連結庫的客戶端記錄,以更詳細瞭解用戶端何時將特定要求傳送至記憶體服務。

記憶體客戶端連結庫所產生的下列用戶端記錄說明用戶端找不到所建立 Blob 的容器時發生的問題。 此記錄檔包含下列記憶體作業的詳細資料:

要求識別碼 作業
07b26a5d-... DeleteIfExists 刪除 Blob 容器的方法。 請注意,此作業包含 HEAD 檢查容器是否存在的要求。
e2d06d78... CreateIfNotExists 方法來建立 Blob 容器。 請注意,此作業包含 HEAD 檢查容器是否存在的要求。 會 HEAD 傳回 404 訊息,但會繼續。
de8b1c3c-... UploadFromStream 方法來建立 Blob。 要求 PUT 失敗,並顯示 404 訊息。

記錄專案:

要求識別碼 作業文字
07b26a5d-... Starting synchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer.
07b26a5d-... StringToSign = HEAD............x-ms-client-request-id:07b26a5d-....x-ms-date:Tue, 03 Jun 2014 10:33:11 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container.
07b26a5d-... Waiting for response.
07b26a5d-... Response received. Status code = 200, Request ID = eeead849-...Content-MD5 = , ETag = &quot;0x8D14D2DC63D059B&quot;.
07b26a5d-... Response headers were processed successfully, proceeding with the rest of the operation.
07b26a5d-... Downloading response body.
07b26a5d-... Operation completed successfully.
07b26a5d-... Starting synchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer.
07b26a5d-... StringToSign = DELETE............x-ms-client-request-id:07b26a5d-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container.
07b26a5d-... Waiting for response.
07b26a5d-... Response received. Status code = 202, Request ID = 6ab2a4cf-..., Content-MD5 = , ETag = .
07b26a5d-... Response headers were processed successfully, proceeding with the rest of the operation.
07b26a5d-... Downloading response body.
07b26a5d-... Operation completed successfully.
e2d06d78-... Starting asynchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer.
e2d06d78-... StringToSign = HEAD............x-ms-client-request-id:e2d06d78-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container.
e2d06d78-... Waiting for response.
de8b1c3c-... Starting synchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer/blobCreated.txt.
de8b1c3c-... StringToSign = PUT...64.qCmF+TQLPhq/YYK50mP9ZQ==........x-ms-blob-type:BlockBlob.x-ms-client-request-id:de8b1c3c-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer/blobCreated.txt.
de8b1c3c-... Preparing to write request data.
e2d06d78-... Exception thrown while waiting for response: The remote server returned an error: (404) Not Found..
e2d06d78-... Response received. Status code = 404, Request ID = 353ae3bc-..., Content-MD5 = , ETag = .
e2d06d78-... Response headers were processed successfully, proceeding with the rest of the operation.
e2d06d78-... Downloading response body.
e2d06d78-... Operation completed successfully.
e2d06d78-... Starting asynchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer.
e2d06d78-... StringToSign = PUT...0.........x-ms-client-request-id:e2d06d78-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container.
e2d06d78-... Waiting for response.
de8b1c3c-... Writing request data.
de8b1c3c-... Waiting for response.
e2d06d78-... Exception thrown while waiting for response: The remote server returned an error: (409) Conflict..
e2d06d78-... Response received. Status code = 409, Request ID = c27da20e-..., Content-MD5 = , ETag = .
e2d06d78-... Downloading error response body.
de8b1c3c-... Exception thrown while waiting for response: The remote server returned an error: (404) Not Found..
de8b1c3c-... Response received. Status code = 404, Request ID = 0eaeab3e-..., Content-MD5 = , ETag = .
de8b1c3c-... Exception thrown during the operation: The remote server returned an error: (404) Not Found..
de8b1c3c-... Retry policy did not allow for a retry. Failing with The remote server returned an error: (404) Not Found..
e2d06d78-... Retry policy did not allow for a retry. Failing with The remote server returned an error: (409) Conflict..

在此範例中,記錄顯示用戶端正在交錯來自 CreateIfNotExists 方法的要求, (要求標識碼 e2d06d78...) 與來自 UploadFromStream de8b1c3c (方法的要求-...) 。之所以發生這種交錯,是因為用戶端應用程式會以異步方式叫用這些方法。 修改用戶端中的異步程序代碼,以確保在嘗試將任何數據上傳至該容器中的 Blob 之前,先建立容器。 在理想情況下,您應該事先建立所有容器。

共用存取簽章 (SAS) 授權問題

如果用戶端應用程式嘗試使用未包含作業必要許可權的 SAS 金鑰,記憶體服務會傳回 HTTP 404 (找不到) 訊息給用戶端。 同時,您也會在計量中看到 的非零值 SASAuthorizationError

下表顯示記憶體記錄記錄檔中的範例伺服器端記錄訊息:

名稱
要求開始時間 2014-05-30T06:17:48.4473697Z
作業類型 GetBlobProperties
要求狀態 SASAuthorizationError
HTTP 狀態代碼 404
驗證類型 Sas
服務類型 Blob
要求 URL https://domemaildist.blob.core.windows.net/azureimblobcontainer/blobCreatedViaSAS.txt
  ?sv=2014-02-14&sr=c&si=mypolicy&sig=XXXXX&;api-version=2014-02-14
要求標識符標頭 <要求標識符標頭>
用戶端要求標識碼 <用戶端要求標識碼>

調查用戶端應用程式為何嘗試執行未獲授與許可權的作業。

用戶端 JavaScript 程式代碼沒有存取物件的許可權

如果您使用 JavaScript 用戶端,且記憶體服務正在傳回 HTTP 404 訊息,請在瀏覽器中檢查下列 JavaScript 錯誤:

SEC7120:在 Access-Control-Allow-Origin 標頭中找不到原始 http://localhost:56309 來源。
SCRIPT7002:XMLHttpRequest:網路錯誤0x80070005,存取遭到拒絕。

注意事項

您可以使用 Internet Explorer 中的 F12 開發人員工具,在針對用戶端 JavaScript 問題進行疑難解答時,追蹤瀏覽器與記憶體服務之間交換的訊息。

之所以會發生這些錯誤,是因為網頁瀏覽器會實作 相同的原始 原則安全性限制,以防止網頁從頁面來源的網域呼叫不同網域中的 API。

若要解決 JavaScript 問題,您可以為用戶端所存取的記憶體服務設定跨原始來源資源分享 (CORS) 。 如需詳細資訊,請 參閱跨原始來源資源分享 (CORS) Azure 記憶體服務的支援

下列程式代碼範例示範如何設定 Blob 服務,以允許在 Contoso 網域中執行的 JavaScript 存取 Blob 記憶體服務中的 Blob:

var connectionString = Constants.connectionString;

 BlobServiceClient blobServiceClient = new BlobServiceClient(connectionString);

 BlobServiceProperties sp = blobServiceClient.GetProperties();

 // Set the service properties.
 sp.DefaultServiceVersion = "2013-08-15";
 BlobCorsRule bcr = new BlobCorsRule();
 bcr.AllowedHeaders = "*";

 bcr.AllowedMethods = "GET,POST";
 bcr.AllowedOrigins = "http://www.contoso.com";
 bcr.ExposedHeaders = "x-ms-*";
 bcr.MaxAgeInSeconds = 5;
 sp.Cors.Clear();
 sp.Cors.Add(bcr);
 blobServiceClient.SetProperties(sp);

網路失敗

在某些情況下,遺失的網路封包可能會導致記憶體服務將 HTTP 404 訊息傳回給用戶端。 例如,當您的用戶端應用程式從資料表服務刪除實體時,您會看到用戶端擲回記憶體例外狀況,其中報告來自數據表服務的「HTTP 404 (找不到) 」狀態消息。 當您調查資料表記憶體服務中的數據表時,您會看到服務已依照要求刪除實體。

用戶端中的例外狀況詳細數據包括數據表服務為要求指派的要求標識碼 (7e84f12d...) 。 您可以使用此資訊,在記錄檔的 資料行中 request-id-header 搜尋 ,以找出伺服器端記憶體記錄中的要求詳細數據。 您也可以使用計量來識別發生這類失敗的時間,然後根據度量記錄此錯誤的時間來搜尋記錄檔。 此記錄項目顯示刪除失敗,並出現「HTTP (404) 用戶端其他錯誤」狀態消息。 相同的記錄專案也包含客戶端在 client-request-id 數據行 813ea74f...) (產生的要求識別碼。

伺服器端記錄檔也包含另一個具有相同 client-request-id 值的專案, (813ea74f...) ,以成功刪除相同實體和來自相同客戶端的作業。 此成功的刪除作業在失敗的刪除要求發生之前很快發生。

此案例最可能的原因是用戶端已將實體的刪除要求傳送至數據表服務,該要求成功,但未收到來自伺服器 (可能因為暫時的網路問題) 。 用戶端接著會使用相同的 client-request-id) 自動重試作業 (,而此重試失敗,因為實體已刪除。

如果這個問題經常發生,您應該調查客戶端為何無法從數據表服務收到通知。 如果問題是間歇性的,您應該捕捉「HTTP (404) 找不到」錯誤,並將其記錄在用戶端中,但允許客戶端繼續。

用戶端收到 HTTP 409 (衝突) 訊息

下表顯示從伺服器端記錄中擷取兩個用戶端作業: DeleteIfExists 緊接著 CreateIfNotExists 使用相同的 Blob 容器名稱。 每個用戶端作業都會產生兩個傳送至伺服器的要求,第一個 GetContainerProperties 要求是檢查容器是否存在,後面接著 DeleteContainerCreateContainer 要求。

時間戳記 作業 結果 容器名稱 用戶端要求標識碼
05:10:13.7167225 GetContainerProperties 200 mmcont c9f52c89-...
05:10:13.8167325 DeleteContainer 202 mmcont c9f52c89-...
05:10:13.8987407 GetContainerProperties 404 mmcont bc881924-...
05:10:14.2147723 CreateContainer 409 mmcont bc881924-...

用戶端應用程式中的程式代碼會刪除,然後使用相同的名稱立即重新建立 Blob 容器: CreateIfNotExists 方法 (用戶端要求標識碼 bc881924-...) 最终会失败,並出現 HTTP 409 (衝突) 錯誤。 當用戶端刪除 Blob 容器、數據表或佇列時,在名稱再次變成可用之前會有一小段時間。

如果刪除/重新建立模式很常見,用戶端應用程式應該在每次建立新容器時使用唯一的容器名稱。

度量顯示低 PercentSuccess 或分析記錄專案具有交易狀態為 ClientOtherErrors 的作業

PercentSuccess 計量會根據作業的 HTTP 狀態代碼,擷取成功的作業百分比。 狀態代碼為 2XX 的作業會計算為成功,而狀態代碼為 3XX、4XX 和 5XX 範圍的作業則會計算為不成功,並降低 PercentSuccess 計量值。 在伺服器端記憶體記錄檔中,這些作業會以 ClientOtherErrors 的交易狀態記錄。

請務必注意,這些作業已順利完成,因此不會影響其他計量,例如可用性。 一些成功執行但可能會導致 HTTP 狀態代碼失敗的作業範例包括:

  • ResourceNotFound (找不到 404) ,例如,從 GET 要求到不存在的 Blob。
  • ResourceAlreadyExists (衝突 409) ,例如,來自 CreateIfNotExist 已存在資源的作業。
  • ConditionNotMet (未修改 304) ,例如,從條件式作業,例如當用戶端傳送 ETag 值和 HTTP If-None-Match 標頭來要求映射自上次作業以來已更新時。

您可以在常見 REST API 錯誤碼頁面上找到記憶體服務傳回的常見 REST API 錯誤碼清單。

容量計量顯示記憶體容量使用量意外增加

如果您在記憶體帳戶中看到突然的非預期容量使用量變更,您可以先查看可用性計量來調查原因;例如,刪除要求失敗的數目增加,可能會導致您用來作為應用程式特定清除作業的 Blob 記憶體數量增加,例如, (因為用來釋放空間的 SAS 令牌已過期) 。

使用記憶體模擬器進行開發或測試會產生您的問題

您通常會在開發和測試期間使用記憶體模擬器,以避免 Azure 記憶體帳戶的需求。 使用記憶體模擬器時可能發生的常見問題如下:

記憶體模擬器中的功能 「X」 無法運作

記憶體模擬器不支援 Azure 記憶體服務的所有功能,例如檔案服務。 如需詳細資訊,請 參閱使用 Azure 記憶體模擬器進行開發和測試

針對記憶體模擬器不支援的功能,請使用雲端中的 Azure 記憶體服務。

使用記憶體模擬器時發生錯誤「其中一個 HTTP 標頭的值格式不正確」

您正在測試針對本機記憶體模擬器使用記憶體用戶端連結庫的應用程式,以及失敗之類的 CreateIfNotExists 方法呼叫,並出現錯誤訊息「其中一個 HTTP 標頭的值格式不正確」。這表示您使用的記憶體模擬器版本不支援您所使用的記憶體用戶端連結庫版本。 記憶體客戶端連結庫會將標 x-ms-version 頭新增至其提出的所有要求。 如果記憶體模擬器無法辨識標頭中的 x-ms-version 值,則會拒絕要求。

您可以使用記憶體連結庫客戶端記錄來查看其所傳送的 x-ms-version header 值。 如果您使用 Fiddler 來追蹤來自用戶端應用程式的要求,您也可以查看的 x-ms-version header 值。

如果您安裝並使用最新版的記憶體用戶端連結庫,而不更新記憶體模擬器,通常會發生此案例。 您應該安裝最新版的記憶體模擬器,或使用雲端記憶體,而不是用於開發和測試的模擬器。

執行記憶體模擬器需要系統管理許可權

當您執行記憶體模擬器時,系統會提示您輸入系統管理員認證。 只有當您第一次初始化記憶體模擬器時,才會發生這種情況。 初始化記憶體模擬器之後,您不需要系統管理許可權即可再次執行它。

如需詳細資訊,請 參閱使用 Azure 記憶體模擬器進行開發和測試。 您也可以在 Visual Studio 中初始化記憶體模擬器,這也需要系統管理許可權。

您在安裝適用於 .NET 的 Azure SDK 時遇到問題

當您嘗試安裝 SDK 時,嘗試在本機電腦上安裝記憶體模擬器時會失敗。 安裝記錄檔包含下列其中一個訊息:

  • CAQuietExec:錯誤:無法存取 SQL 實例
  • CAQuietExec:錯誤:無法建立資料庫

原因是現有 LocalDB 安裝發生問題。 根據預設,記憶體模擬器會在模擬 Azure 記憶體服務時,使用 LocalDB 來保存數據。 您可以在命令提示字元視窗中執行下列命令,然後再嘗試安裝 SDK,以重設 LocalDB 實例。

sqllocaldb stop v11.0
sqllocaldb delete v11.0
delete %USERPROFILE%\WAStorageEmulatorDb3*.*
sqllocaldb create v11.0

命令 delete 會從先前的記憶體模擬器安裝中移除任何舊的資料庫檔案。

您對記憶體服務有不同的問題

如果先前的疑難解答章節未包含您在記憶體服務中遇到的問題,您應該採用下列方法來診斷和疑難解答您的問題。

  • 檢查您的計量,以查看您預期的基準行為是否有任何變更。 從計量中,您可以判斷問題是暫時性還是永久性,以及問題所影響的記憶體作業。
  • 您可以使用計量資訊來協助您搜尋伺服器端記錄數據,以取得任何發生之錯誤的詳細資訊。 此資訊可協助您進行疑難解答並解決問題。
  • 如果伺服器端記錄中的資訊不足以成功針對問題進行疑難解答,您可以使用記憶體用戶端連結庫客戶端記錄來調查用戶端應用程式的行為,以及 Fiddler 和 Wireshark 等工具來調查您的網路。

如需使用 Fiddler 的詳細資訊,請參閱 附錄 1:使用 Fiddler 擷取 HTTP 和 HTTPS 流量

如需使用Wireshark的詳細資訊,請參閱 附錄 2:使用Wireshark擷取網路流量

附錄

這些附錄說明當您診斷 Azure 記憶體 (和其他服務) 的問題並進行疑難解答時,可能會發現有用的數個工具。 這些工具不是 Azure 記憶體的一部分,有些是第三方產品。 因此,您可能與 Microsoft Azure 或 Azure 記憶體簽訂的任何支援合約並未涵蓋這些附錄中所討論的工具。 因此,在評估程式中,您應該檢查這些工具提供者提供的授權和支援選項。

附錄 1:使用 Fiddler 擷取 HTTP 和 HTTPS 流量

Fiddler 是一個實用的工具,可用來分析用戶端應用程式與您所使用 Azure 記憶體服務之間的 HTTP 和 HTTPS 流量。

注意事項

Fiddler 可以譯碼 HTTPS 流量。 您應該仔細閱讀 Fiddler 檔,以瞭解其執行方式及其安全性影響。

本附錄提供如何設定 Fiddler 以擷取您已安裝 Fiddler 的本機電腦與 Azure 記憶體服務之間流量的簡短逐步解說。

啟動 Fiddler 之後,它會開始擷取本機電腦上的 HTTP 和 HTTPS 流量。 以下是用來控制 Fiddler 的一些實用命令:

  • 停止並開始擷取流量。 在主功能表上,移至 [檔案 ],然後選取 [擷 取流量 ] 以開啟和關閉擷取。
  • 儲存擷取的流量數據。 在主功能表上,移至 [檔案],選取 [ 儲存],然後選取 [ 所有會話]。 這可讓您將流量儲存在會話封存盤案中。 您可以稍後重載會話封存以進行分析,或在要求 Microsoft 支援服務時傳送它。

若要限制 Fiddler 所擷取的流量,您可以使用您在 [篩選] 索引標籤中設定 篩選。下列螢幕快照顯示僅擷取傳送至記憶體端點之流量的 contosoemaildist.table.core.windows.net 篩選條件:

顯示僅擷取傳送至 contosoemaildist.table.core.windows.net 記憶體端點之流量的篩選器螢幕快照。

附錄 2:使用Wireshark擷取網路流量

Wireshark 是一種網路協定分析器,可讓您檢視各種網路協議的詳細封包資訊。

下列程式示範如何擷取從您安裝Wireshark的本機電腦到 Azure 記憶體帳戶中數據表服務的流量詳細封包資訊。

  1. 在本機計算機上啟動Wireshark。

  2. 在 [ 開始 ] 區段中,選取連線到因特網的局域網路介面或介面。

  3. 取 [擷取選項]

  4. 將篩選新增至 [擷 取篩選 ] 文本框。 例如, host contosoemaildist.table.core.windows.net 會設定 Wireshark 只擷取傳送至 contosoemaildist 記憶體帳戶中數據表服務端點或從數據表服務端點傳送的封包。 查看 擷取篩選器的完整清單

    顯示如何將篩選新增至 [擷取篩選] 文本框的螢幕快照。

  5. 選取 [開始]。 當您在本機計算機上使用用戶端應用程式時,Wireshark 現在會擷取傳送至數據表服務端點或從數據表服務端點傳送的所有封包。

  6. 當您完成時,請選取主功能表上的 [擷 >停止 ]。

  7. 若要將擷取的數據儲存在Wireshark擷取檔案中,請選取主功能表上的[檔案>儲存]。

WireShark 會反白顯示封 包清單 視窗中存在的任何錯誤。 您也可以使用 [ 專家資訊] 視窗 (選取 [ 分析>專家資訊) 來檢視錯誤和警告的摘要。

顯示 [專家資訊] 視窗的螢幕快照,您可以在其中檢視錯誤和警告的摘要。

您也可以選擇在應用層看到 TCP 數據時,以滑鼠右鍵按下 TCP 數據,然後選取 [追蹤 TCP Stream。 如果您擷取傾印時沒有擷取篩選器,這會很有用。 如需詳細資訊,請 參閱追蹤 TCP 數據流

顯示如何在應用層看到 TCP 數據時檢視數據的螢幕快照。

注意事項

如需使用Wireshark的詳細資訊,請參閱 Wireshark使用者指南

附錄 4:使用 Excel 檢視計量和記錄數據

許多工具可讓您以分隔格式從 Azure 資料表記憶體下載記憶體下載記憶體計量數據,讓您輕鬆地將數據載入 Excel 以進行檢視和分析。 來自 Azure Blob 儲存體的記憶體記錄數據已經是可載入 Excel 的分隔格式。 不過,您必須根據 儲存體分析 記錄格式和 儲存體分析度量數據表架構中的資訊,新增適當的數據行標題。

從 Blob 記憶體下載記憶體之後,若要將記憶體記錄數據匯入 Excel:

  • 在 [ 數據] 功能表上,選取 [ 從文字]
  • 流覽至您想要檢視的記錄檔,然後選取 [ 匯入]
  • [文字匯入精靈] 的步驟 1 中,選取 [ 分隔符]

[文字匯入精靈] 的步驟 1 中,選取 [ 分號 ] 作為唯一的分隔符,然後選擇雙引號作為文字限定 。 然後選 取 [完成] ,然後選擇要在活頁簿中放置數據的位置。

附錄 5:使用適用於 Azure DevOps 的 Application Insights 進行監視

您也可以使用適用於 Azure DevOps 的 Application Insights 功能,作為效能和可用性監視的一部分。 此工具可以:

  • 請確定您的 Web 服務可供使用且有回應。 無論您的應用程式是網站或使用 Web 服務的裝置應用程式,都可以每隔幾分鐘從全球位置測試您的 URL,並讓您知道是否有問題。
  • 快速診斷 Web 服務中的任何效能問題或例外狀況。 瞭解 CPU 或其他資源是否正在延展、從例外狀況取得堆疊追蹤,以及輕鬆地搜尋記錄追蹤。 如果應用程式的效能低於可接受的限制,Microsoft 可以傳送電子郵件給您。 您可以同時監視 .NET 和 Java Web 服務。

您可以在 什麼是 Application Insights 找到詳細資訊。

後續步驟

如需 Azure 記憶體中分析的詳細資訊,請參閱下列資源:

協力廠商資訊免責聲明

本文提及的協力廠商產品是由與 Microsoft 無關的獨立廠商所製造。 Microsoft 不以默示或其他方式,提供與這些產品的效能或可靠性有關的擔保。

與我們連絡,以取得說明

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