Behandeln von Problemen mit der Leistung in Azure-Speicherkonten

Dieser Artikel hilft Ihnen bei der Untersuchung unerwarteter Verhaltensänderungen (z. B. langsamere als übliche Reaktionszeiten). Diese Änderungen im Verhalten können häufig durch das Überwachen von Speichermetriken in Azure Monitor identifiziert werden. Allgemeine Informationen zur Verwendung von Metriken und Protokollen in Azure Monitor finden Sie in den folgenden Artikeln:

• Überwachen von Azure Blob Storage
• Überwachen von Azure Files
• Überwachen von Azure Queue Storage
• Überwachen von Azure-Tabellenspeicher

Leistungsüberwachung

Um die Leistung der Speicherdienste zu überwachen, können Sie die folgenden Metriken verwenden:

• Die Metriken SuccessE2ELatency und SuccessServerLatency geben Aufschluss über die vom Speicherdienst oder von der API-Vorgangsart benötigte Durchschnittszeit für die Anforderungsverarbeitung. SuccessE2ELatency ist ein Maß für die End-to-End-Latenz, die die Zeit enthält, die zum Lesen der Anforderung und zum Senden der Antwort erforderlich ist, zusätzlich zu der Zeit, die für die Verarbeitung der Anforderung erforderlich ist (daher umfasst sie die Netzwerklatenz, sobald die Anforderung den Speicherdienst erreicht). SuccessServerLatency ist ein Maß für die Verarbeitungszeit und schließt daher alle Netzwerklatenz im Zusammenhang mit der Kommunikation mit dem Client aus.

• Die Metriken Egress und Ingress zeigen die Gesamtdatenmenge (in Bytes), die bei Ihrem Speicherdienst eingehen oder von ihm ausgehen bzw. eine bestimmte API-Vorgangsart durchlaufen.

• Die Metrik Transactions zeigt die Gesamtzahl der Anfragen an, die beim Speicherdienst des API-Vorgangs eingehen. Transaktionen sind die Gesamtzahl der Anforderungen, die der Speicherdienst empfängt.

Sie können unerwartete Änderungen in allen diesen Werten überwachen. Diese Änderungen könnten auf ein Problem hinweisen, für das weitere Untersuchungen erforderlich sind.

Im Azure-Portal können Sie Warnungsregeln hinzufügen, die Sie benachrichtigen, wenn eine der Leistungsmetriken für diesen Dienst unterschreitet oder einen von Ihnen angegebenen Schwellenwert überschreitet.

Suchen und Diagnostizieren von Leistungsproblemen mit Azure Application Insights

Die Leistungsfähigkeit einer Anwendung kann subjektiv sein, vor allem aus der Benutzerperspektive. Daher ist es wichtig, Baseline-Metriken zur Verfügung zu haben, um Leistungsprobleme identifizieren zu können. Viele Faktoren können die Leistung eines Azure-Speicherdiensts aus der Client-Anwendungs-Perspektive beeinflussen. Diese Faktoren können im Speicherdienst, dem Client oder der Netzwerkinfrastruktur ausgeführt werden. Daher ist es wichtig, eine Strategie zur Identifizierung des Ursprungs des Leistungsproblems zu haben.

Nachdem Sie anhand der Messdaten ermittelt haben, wo die mögliche Ursache des Leistungsproblems liegt, können Sie anschließend die Protokollierungsdateien verwenden, um detaillierte Informationen zur Diagnose und weiteren Problembehandlung zu erhalten.

Metriken zeigen hohe Werte für SuccessE2ELatency und niedrige Werte für SuccessServerLatency

In einigen Fällen stellen Sie möglicherweise fest, dass SuccessE2ELatency höher als die SuccessServerLatency ist. Der Speicherdienst berechnet die Metrik SuccessE2ELatency nur für erfolgreiche Anforderungen und bezieht dabei im Gegensatz zu SuccessServerLatency die Zeit ein, die der Client zum Senden der Daten und zum Empfangen der Bestätigung des Speicherdiensts benötigt. Daher könnte ein Unterschied zwischen SuccessE2ELatency und SuccessServerLatency entweder darauf zurückzuführen sein, dass die Clientanwendung langsam reagiert oder aufgrund von Bedingungen im Netzwerk reagiert.

Notiz

Sie können E2ELatency und ServerLatency auch für einzelne Speichervorgänge in den Protokolldaten der Speicherprotokollierung anzeigen.

Untersuchung von Clientleistungsproblemen

Mögliche Gründe für die langsame Reaktion des Clients sind eingeschränkte verfügbare Verbindungen oder Threads oder geringe Ressourcen wie CPU, Arbeitsspeicher oder Netzwerkbandbreite. Möglicherweise können Sie das Problem beheben, indem Sie den Clientcode so ändern, dass er effizienter ist (z. B. mithilfe asynchroner Aufrufe des Speicherdiensts) oder mithilfe eines größeren virtuellen Computers mit mehr Kernen und mehr Arbeitsspeicher.

Für die Tabellen- und Warteschlangendienste kann der Nagle-Algorithmus auch eine hohe SuccessE2ELatency im Vergleich zu SuccessServerLatency verursachen. Weitere Informationen finden Sie im Beitrag Nagle's Algorithm ist nicht für kleine Anforderungen geeignet. Sie können den Nagle-Algorithmus im Code deaktivieren, indem Sie die ServicePointManager Klasse im System.Net Namespace verwenden. Sie sollten dies tun, bevor Sie Aufrufe an die Tabellen- oder Warteschlangendienste in Ihrer Anwendung senden, da dies keinen Einfluss auf die bereits offenen Verbindungen hat. Das folgende Beispiel stammt aus der Application_Start Methode in einer Workerrolle:

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

Überprüfen Sie die clientseitigen Protokolle, um zu sehen, wie viele Anforderungen Ihre Clientanwendung übermittelt, und überprüfen Sie allgemeine .NET-bezogene Leistungsengpässe in Ihrem Client, z. B. CPU, .NET Garbage Collection, Netzwerkauslastung oder Arbeitsspeicher. Als Ausgangspunkt für die Fehlerbehandlung bei .NET-Clientanwendungen siehe Debuggen, Ablaufverfolgung und Profilerstellung.

Untersuchung von Netzwerklatenzproblemen

In der Regel wird eine hohe durchgängige Latenz durch die Übermittlungsbedingungen im Netzwerk verursacht. Sie können vorübergehende und dauerhafte Netzwerkprobleme wie verworfene Pakete mithilfe von Tools wie Wireshark untersuchen.

Metriken zeigen niedrige Werte für SuccessE2ELatency und SuccessServerLatency an, aber im Client tritt eine hohe Latenz auf

In diesem Szenario ist ein verzögertes Erreichen des Speicherdiensts durch die Speicheranforderungen die wahrscheinlichste Ursache. Sie sollten untersuchen, warum Anforderungen vom Client nicht an den BLOB-Dienst weitergeleitet werden.

Ein möglicher Grund für das verzögerte Senden von Anfragen durch den Client ist z. B. eine begrenzte Anzahl verfügbarer Verbindungen oder Threads.

Überprüfen Sie außerdem, ob der Client mehrere Wiederholungsversuche durchführt, und untersuchen Sie den Grund, ob er vorhanden ist. Um zu ermitteln, ob der Client mehrere Wiederholungen ausführt, können Sie folgende Aktionen ausführen:

• Untersuchen Sie die Protokolle. Wenn mehrere Wiederholungen ausgeführt werden, werden mehrere Vorgänge mit denselben Clientanforderungs-IDs angezeigt.

• Überprüfen Sie die Clientprotokolle. Bei einer ausführlichen Protokollierung wird auch angezeigt, dass ein erneuter Versuch erfolgt ist.

• Debuggen Sie Ihren Code, und überprüfen Sie die Eigenschaften des Objekts, das OperationContext der Anforderung zugeordnet ist. Wenn der Vorgang wiederholt wurde, enthält die RequestResults Eigenschaft mehrere eindeutige Anforderungen. Sie können auch die Start- und Endzeiten der einzelnen Anforderungen überprüfen.

Wenn das Problem nicht beim Client liegt, sollten Sie potenzielle Netzwerkprobleme wie Paketverlust untersuchen. Sie können Tools wie Wireshark verwenden, um Netzwerkprobleme zu untersuchen.

Metriken zeigen hohe Werte für SuccessServerLatency an

Im Fall von hoher SuccessServerLatency bei Blob-Download-Anforderungen sollten Sie die Speicherprotokolle verwenden, um herauszufinden, ob wiederholte Anforderungen für den gleichen Blob (oder die gleiche Blobgruppe) vorliegen. Bei Blob-Uploadanforderungen sollten Sie untersuchen, welche Blockgröße der Client verwendet (z. B. Blöcke mit weniger als 64 K Größe können zu Mehraufwand führen, es sei denn, die Lesevorgänge befinden sich auch in weniger als 64 K-Blöcken) und wenn mehrere Clients Blöcke parallel in dasselbe Blob hochladen. Sie sollten auch die Metriken pro Minute auf Spitzen in der Anzahl der Anforderungen überprüfen, die zu einer Überschreitung der Skalierbarkeitsziele pro Sekunde führen.

Wenn für Blob-Downloadanforderungen hohe SuccessServerLatency-Anforderungen angezeigt werden, wenn wiederholte Anforderungen für dasselbe Blob oder dieselbe Gruppe von Blobs vorhanden sind, sollten Sie diese Blobs mithilfe des Azure-Caches oder des Azure Content Delivery Network (CDN) zwischenspeichern. In Bezug auf Upload-Anfragen können Sie den Durchlauf durch Verwendung einer größeren Blockgröße verbessern. Für Abfragen in Tabellen kann auch clientseitiges Caching auf Clients implementiert werden, die die gleichen Abfrageoperationen durchführen und deren Daten sich nicht häufig ändern.

Hohe Werte bei der SuccessServerLatency können auch ein Zeichen für schlecht entworfene Tabellen oder Abfragen sein, die zu Scanoperationen führen oder die dem angehängten/vorangestellten Gegenmuster folgen.

Notiz

Eine umfassende Leistungsprüfliste finden Sie in der Prüfliste zu Microsoft Azure Storage Performance and Skalierbarkeit.

Sie stoßen auf unerwartete Verzögerungen bei der Nachrichtenübermittlung in einer Warteschlange

Wenn zwischen dem Zeitpunkt, zu dem eine Anwendung eine Nachricht zu einer Warteschlange hinzufügt, eine Verzögerung auftritt und der Zeitpunkt, zu dem sie zum Lesen aus der Warteschlange verfügbar ist, führen Sie die folgenden Schritte aus, um das Problem zu diagnostizieren:

• Stellen Sie sicher, dass die Anwendung die Nachrichten erfolgreich zur Warteschlange hinzufügt. Überprüfen Sie, ob die Anwendung die AddMessage Methode nicht mehrmals wiederholt, bevor sie erfolgreich ausgeführt wird.

• Vergewissern Sie sich, dass zwischen der Workerrolle keine Uhr schief ist, die die Nachricht der Warteschlange und der Workerrolle hinzufügt, die die Nachricht aus der Warteschlange liest. Eine Uhr-Schiefe macht es so aus, als ob es eine Verzögerung bei der Verarbeitung gibt.

• Prüfen Sie, ob der Fehler bei der Workerrolle liegt, die die Nachrichten aus der Warteschlange liest. Wenn ein Warteschlangenclient die GetMessage Methode aufruft, aber nicht mit einer Bestätigung antwortet, bleibt die Nachricht bis zum Ablauf des invisibilityTimeout Zeitraums in der Warteschlange unsichtbar. An diesem Punkt steht die Nachricht wieder zur Verarbeitung zur Verfügung.

• Prüfen Sie, ob die Länge der Warteschlange im Laufe der Zeit wächst. Dies kann auftreten, wenn Sie nicht über ausreichende Mitarbeiter verfügen, um alle Nachrichten zu verarbeiten, die andere Mitarbeiter in der Warteschlange platzieren. Überprüfen Sie außerdem die Metriken, um festzustellen, ob Löschanforderungen fehlschlagen, und die Anzahl der Benachrichtigungen, die auf wiederholte fehlgeschlagene Versuche zum Löschen der Nachricht hinweisen können.

• Untersuchen Sie die Speicherprotokolle auf Warteschlangenvorgänge, die für einen ungewöhnlich langen Zeitraum über höhere Werte für E2ELatency und ServerLatency verfügen.

Weitere Informationen

• Behandeln von Clientanwendungsfehlern
• Behandeln von Verfügbarkeitsproblemen
• Überwachung, Diagnose und Problembehandlung in Azure Storage

Kontaktieren Sie uns für Hilfe

Wenn Sie Fragen haben oder Hilfe mit Ihren Azure-Gutschriften benötigen, dann erstellen Sie beim Azure-Support eine Support-Anforderung oder fragen Sie den Azure Community-Support. Sie können auch Produktfeedback an die Azure Feedback Community senden.