Problembehandlung bei der Leistung in Azure-Speicherkonten

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

• Überwachung Azure Blob Storage
• Überwachung Azure Files
• Überwachen von Azure Queue Storage
• Überwachen von Azure Table Storage

Überwachen der Leistung

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

• Die Metriken SuccessE2ELatency und SuccessServerLatency zeigen die durchschnittliche Zeit an, die der Speicherdienst oder API-Vorgangstyp für die Verarbeitung von Anforderungen in Anspruch nimmt. SuccessE2ELatency ist ein Maß für die End-to-End-Latenz, das die Zeit einschließt, die zum Lesen der Anforderung und zum Senden der Antwort erforderlich ist, zusätzlich zur Zeit, die für die Verarbeitung der Anforderung erforderlich ist (daher umfasst es die Netzwerklatenz, sobald die Anforderung den Speicherdienst erreicht hat). SuccessServerLatency ist ein Maß für die Verarbeitungszeit und schließt daher jede Netzwerklatenz im Zusammenhang mit der Kommunikation mit dem Client aus.

• Die Metriken "Ausgehend " und " Eingehender Datenverkehr" zeigen die Gesamtmenge der Daten in Bytes an, die in Ihren Speicherdienst ein- und ausgehend werden, oder über einen bestimmten API-Vorgangstyp.

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

Sie können einen dieser Werte auf unerwartete Änderungen überwachen. Diese Änderungen können auf ein Problem hinweisen, das eine weitere Untersuchung erfordert.

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

Diagnostizieren von Leistungsproblemen

Die Leistung einer Anwendung kann subjektiv sein, insbesondere aus Benutzersicht. Daher ist es wichtig, baseline-Metriken zur Verfügung zu haben, damit Sie ermitteln können, wo ein Leistungsproblem vorliegt. Aus Sicht der Clientanwendung können sich viele Faktoren auf die Leistung eines Azure-Speicherdiensts auswirken. Diese Faktoren können im Speicherdienst, auf dem Client oder in der Netzwerkinfrastruktur ausgeführt werden. Daher ist es wichtig, eine Strategie zu haben, um den Ursprung des Leistungsproblems zu identifizieren.

Nachdem Sie den wahrscheinlichen Speicherort der Ursache des Leistungsproblems anhand der Metriken ermittelt haben, können Sie die Protokolldateien verwenden, um detaillierte Informationen zu finden, um das Problem weiter zu diagnostizieren und zu beheben.

Metriken zeigen hohe SuccessE2ELatency und niedrige SuccessServerLatency an.

In einigen Fällen stellen Sie möglicherweise fest, dass SuccessE2ELatency höher als SuccessServerLatency ist. Der Speicherdienst berechnet nur die Metrik SuccessE2ELatency für erfolgreiche Anforderungen und enthält im Gegensatz zu SuccessServerLatency die Zeit, die der Client benötigt, um die Daten zu senden und eine Bestätigung vom Speicherdienst zu empfangen. Daher kann ein Unterschied zwischen SuccessE2ELatency und SuccessServerLatency entweder darauf zurückzuführen sein, dass die Clientanwendung langsam reagiert oder auf Bedingungen im Netzwerk zurückzuführen ist.

Hinweis

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

Untersuchen von Clientleistungsproblemen

Mögliche Gründe dafür, dass der Client langsam reagiert, sind begrenzte Verbindungen oder Threads oder wenig 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. durch asynchrone Aufrufe des Speicherdiensts), oder indem Sie einen größeren virtuellen Computer mit mehr Kernen und mehr Arbeitsspeicher verwenden.

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 Nagles Algorithmus ist für kleine Anforderungen nicht freundlich. Sie können den Nagle-Algorithmus im Code mithilfe der ServicePointManager -Klasse im System.Net -Namespace deaktivieren. Dies sollten Sie tun, bevor Sie aufruft die Tabellen- oder Warteschlangendienste in Ihrer Anwendung, da dies keine Auswirkungen auf bereits geöffnete 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;

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

Untersuchen von Netzwerklatenzproblemen

In der Regel ist eine hohe End-to-End-Latenz, die durch das Netzwerk verursacht wird, auf vorübergehende Bedingungen zurückzuführen. Sie können sowohl vorübergehende als auch persistente Netzwerkprobleme wie verworfene Pakete mithilfe von Tools wie Wireshark untersuchen.

Metriken zeigen eine niedrige SuccessE2ELatency und eine niedrige SuccessServerLatency an, aber der Client weist eine hohe Latenz auf.

In diesem Szenario ist die wahrscheinlichste Ursache eine Verzögerung der Speicheranforderung beim Erreichen des Speicherdiensts. Sie sollten untersuchen, warum Anforderungen vom Client nicht an den Blobdienst weitergeleitet werden.

Ein möglicher Grund dafür, dass der Client das Senden von Anforderungen verzögert, ist die begrenzte Anzahl verfügbarer Verbindungen oder Threads.

Überprüfen Sie außerdem, ob der Client mehrere Wiederholungen ausführt, und untersuchen Sie, warum dies der Fall ist. Um zu bestimmen, ob der Client mehrere Wiederholungen ausführt, können Sie:

• Untersuchen von Protokollen. Wenn mehrere Wiederholungen ausgeführt werden, werden mehrere Vorgänge mit den gleichen Clientanforderungs-IDs angezeigt.

• Untersuchen Sie die Clientprotokolle. Die ausführliche Protokollierung gibt an, dass ein Wiederholungsversuch stattgefunden hat.

• 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 für jede Anforderung überprüfen.

Wenn keine Probleme auf dem Client vorliegen, sollten Sie potenzielle Netzwerkprobleme wie Paketverlust untersuchen. Sie können Tools wie Wireshark verwenden, um Netzwerkprobleme zu untersuchen.

Metriken zeigen eine hohe SuccessServerLatency an

Im Fall einer hohen SuccessServerLatency für Blobdownloadanforderungen sollten Sie die Speicherprotokolle verwenden, um festzustellen, ob wiederholte Anforderungen für dasselbe Blob (oder eine Gruppe von Blobs) vorhanden sind. Bei Blobuploadanforderungen sollten Sie untersuchen, welche Blockgröße der Client verwendet (z. B. können Blöcke mit einer Größe von weniger als 64 K zu Mehraufwand führen, es sei denn, die Lesevorgänge befinden sich auch in weniger als 64.000 Blöcken) und wenn mehrere Clients Blöcke parallel in dasselbe Blob hochladen. Sie sollten auch die Minutenmetriken auf Spitzen bei der Anzahl der Anforderungen überprüfen, die zur Überschreitung der Skalierbarkeitsziele pro Sekunde führen.

Wenn eine hohe SuccessServerLatency für Blobdownloadanforderungen angezeigt wird, wenn wiederholte Anforderungen für dasselbe Blob oder dieselbe Gruppe von Blobs vorhanden sind, sollten Sie diese Blobs mithilfe von Azure Cache oder dem Azure Content Delivery Network (CDN) zwischenspeichern. Bei Uploadanforderungen können Sie den Durchsatz verbessern, indem Sie eine größere Blockgröße verwenden. Für Abfragen von Tabellen ist es auch möglich, die clientseitige Zwischenspeicherung auf Clients zu implementieren, die dieselben Abfragevorgänge ausführen und bei denen sich die Daten nicht häufig ändern.

Hohe SuccessServerLatency-Werte können auch ein Symptom schlecht entworfener Tabellen oder Abfragen sein, die zu Scanvorgängen führen oder dem Anfüge-/Prepend-Antimuster folgen.

Hinweis

Eine umfassende Leistungsprüfliste finden Sie in Microsoft Azure Storage Checkliste für Leistung und Skalierbarkeit.

Unerwartete Verzögerungen bei der Nachrichtenübermittlung in einer Warteschlange

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

• Stellen Sie sicher, dass die Anwendung die Nachrichten erfolgreich zur Warteschlange hinzugefügt hat. Überprüfen Sie, ob die Anwendung die AddMessage Methode nicht mehrmals wiederholt, bevor sie erfolgreich ist.

• Stellen Sie sicher, dass zwischen der Workerrolle, die die Nachricht der Warteschlange hinzufügt, und der Workerrolle, die die Nachricht aus der Warteschlange liest, keine Uhrabweichung besteht. Eine Uhrschiefe lässt den Eindruck entstehen, als ob es eine Verzögerung bei der Verarbeitung gibt.

• Überprüfen Sie, ob die Workerrolle, die die Nachrichten aus der Warteschlange liest, fehlschlägt. Wenn ein Warteschlangenclient die GetMessage -Methode aufruft, aber nicht mit einer Bestätigung antwortet, bleibt die Nachricht in der Warteschlange unsichtbar, bis der invisibilityTimeout Zeitraum abläuft. An diesem Punkt wird die Nachricht wieder für die Verarbeitung verfügbar.

• Überprüfen Sie, ob die Warteschlangenlänge im Laufe der Zeit zunimmt. Dies kann auftreten, wenn Nicht genügend Worker verfügbar sind, um alle Nachrichten zu verarbeiten, die andere Worker in die Warteschlange stellen. Überprüfen Sie außerdem die Metriken, um zu ermitteln, ob Löschanforderungen fehlschlagen, und die Anzahl der Meldungen, die aus der Warteschlange entfernt werden, was auf wiederholte fehlgeschlagene Versuche zum Löschen der Nachricht hindeuten kann.

• Überprüfen Sie die Speicherprotokolle auf alle Warteschlangenvorgänge, die über einen längeren Zeitraum als üblich höhere E2ELatency - und ServerLatency-Werte aufweisen als erwartet.

Siehe auch

• Beheben von Clientanwendungsfehlern
• Behandeln von Verfügbarkeitsproblemen
• Überwachen, Diagnostizieren und Beheben von Problemen mit 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.