Diagnose und Troubleshooting bei .NET SDK-Anforderungstimeoutausnahmen in Azure Cosmos DB

  • Artikel

GILT FÜR: NoSQL

Der Fehler „HTTP-408“ tritt auf, wenn das SDK die Anforderung nicht abschließen konnte, bevor das Timeoutlimit überschritten wurde.

Es ist wichtig sicherzustellen, dass das Anwendungsdesign unserem Leitfaden zum Entwerfen robuster Anwendungen mit Azure Cosmos DB SDKs folgt, um sicherzustellen, dass es korrekt auf unterschiedliche Netzwerkbedingungen reagiert. Ihre Anwendung sollte Wiederholungen für Timeoutfehler bereitstellen, da diese normalerweise in einem verteilten System erwartet werden.

Bei der Bewertung des Falls von Timeoutfehlern:

  • Wie groß ist die Auswirkung gemessen an der Menge der betroffenen Vorgänge im Vergleich zu den erfolgreichen Vorgängen? Liegt dieser Wert innerhalb der Dienst-SLAs?
  • Ist die P99-Latenz/-Verfügbarkeit betroffen?
  • Betreffen die Fehler alle Ihre Anwendungsinstanzen oder nur einen Teil? Wenn sich das Problem auf einen Teil der Instanzen beschränkt, handelt es sich in der Regel um ein Problem, das mit diesen Instanzen in Zusammenhang steht.

Anpassen des Timeouts beim Azure Cosmos DB .NET SDK

Das SDK verfügt über zwei unterschiedliche Möglichkeiten zum Steuern von Timeouts, die jeweils für einen anderen Bereich gelten.

Timeouts auf Anforderungsebene

Mit der Konfiguration CosmosClientOptions.RequestTimeout (oder ConnectionPolicy.RequestTimeout für SDK v2) können Sie ein Timeout für die Netzwerkanforderung festlegen, nachdem die Anforderung das SDK verlassen hat und sich im Netzwerk befindet, bis eine Antwort empfangen wird.

Mit der Konfiguration CosmosClientOptions.OpenTcpConnectionTimeout (oder ConnectionPolicy.OpenTcpConnectionTimeout für SDK v2) können Sie ein Timeout für die Zeit festlegen, die beim Öffnen einer ersten Verbindung aufgewendet wird. Sobald eine Verbindung geöffnet wurde, verwenden nachfolgende Anforderungen die Verbindung.

Ein von einem Benutzer gestarteter Vorgang kann mehrere Netzwerkanforderungen umfassen (z. B. Wiederholungen). Diese beiden Konfigurationen sind pro Anforderung und nicht End-to-End für einen Vorgang.

CancellationToken

Alle asynchronen Vorgänge im SDK enthalten einen optionalen CancellationToken-Parameter. Dieser CancellationToken-Parameter wird während des gesamten Vorgangs in allen Netzwerkanforderungen und Wiederholungen verwendet. Zwischen den Netzwerkanforderungen wird das Abbruchtoken (cancellation token) möglicherweise überprüft und ein Vorgang abgebrochen, wenn das zugehörige Token abgelaufen ist. Das Abruftoken (CancellationToken) sollte zum Definieren eines ungefähren erwarteten Timeouts für den Vorgangsbereich verwendet werden.

Hinweis

Der Parameter CancellationToken ist ein Mechanismus, bei dem die Bibliothek den Abbruch überprüft, wenn das zu keinem ungültigen Status führt. Der Vorgang wird möglicherweise nicht exakt abgebrochen, wenn die im Abbruch definierte Zeit abgelaufen ist. Stattdessen wird er nach Ablauf der Zeit dann abgebrochen, wenn dies auf sichere Weise möglich ist.

Schritte zur Problembehandlung

Die folgende Liste enthält bekannte Gründe und Lösungen für Anforderungstimeoutausnahmen.

CosmosOperationCanceledException

Dieser Ausnahmetyp ist üblich, wenn Ihre Anwendung CancellationTokens an die SDK-Vorgänge übergibt. Das SDK überprüft den Zustand der CancellationToken zwischen Wiederholungen. Beim Abbruch von CancellationToken wird der aktuelle Vorgang mit dieser Ausnahme abgebrochen.

Message / ToString() der Ausnahme gibt außerdem den Zustand von CancellationToken über Cancellation Token has expired: true an, und es enthält zudem eine Diagnostics-Eigenschaft, die den Kontext des Abbruchs für die beteiligten Anforderungen enthält.

Diese Ausnahmen können bedenkenlos wiederholt werden und aus der Wiederholungsperspektive als Timeouts behandelt werden.

Lösung

Überprüfen Sie die konfigurierte Zeit in CancellationToken. Stellen Sie sicher, dass der Wert höher ist als für RequestTimeout und CosmosClientOptions.OpenTcpConnectionTimeout (wenn Sie den direkten Modus verwenden). Wenn die verfügbare Zeitspanne in CancellationToken kürzer ist als die konfigurierten Timeouts ist und für das SDK vorübergehende Konnektivitätsprobleme auftreten, kann das SDK keine Wiederholung ausführen und löst CosmosOperationCanceledException aus.

Hohe CPU-Auslastung

Hohe CPU-Auslastung ist der häufigste Fall. Für optimale Latenz sollte die CPU-Auslastung ungefähr 40 Prozent betragen. Verwenden Sie 10 Sekunden als Intervall zur Überwachung der maximalen (nicht durchschnittlichen) CPU-Nutzung. CPU-Spitzenwerte treten bei partitionsübergreifenden Abfragen häufiger auf, wenn es möglicherweise erforderlich ist, mehrere Verbindungen für eine einzelne Abfrage herzustellen.

Die Timeouts enthalten die Diagnose mit:

"systemHistory": [
{
"dateUtc": "2021-11-17T23:38:28.3115496Z",
"cpu": 16.731,
"memory": 9024120.000,
"threadInfo": {
"isThreadStarving": "False",
....
}

},
{
"dateUtc": "2021-11-17T23:38:28.3115496Z",
"cpu": 16.731,
"memory": 9024120.000,
"threadInfo": {
"isThreadStarving": "False",
....
}

},
...
]
  • Wenn die cpu-Werte über 70 % liegen, liegt die Ursache für das Timeout wahrscheinlich bei der zu hohen CPU-Auslastung. In diesem Fall besteht die Lösung darin, die Quelle für die hohe CPU-Auslastung zu ermitteln und für eine Reduzierung zu sorgen oder die Ressourcengröße für den Computer zu erhöhen.
  • Wenn die threadInfo/isThreadStarving-Knoten True-Werte enthalten, ist die Ursache Threadmangel. In diesem Fall besteht die Lösung darin, die Ursachen für den Threadmangel (ggf. gesperrte Threads) zu untersuchen oder die Ressourcengröße für die Computer zu erhöhen.
  • Wenn die dateUtc-Zeit zwischen Messungen nicht ungefähr 10 Sekunden beträgt, würde dies auch auf einen Konflikt im Threadpool hinweisen. Die CPU-Messung erfolgt als unabhängige Aufgabe, die alle 10 Sekunden in die Warteschlange des Threadpools eingereiht wird. Wenn die Zeit zwischen den Messungen länger ist, würde dies darauf hinweisen, dass die asynchronen Aufgaben nicht zeitgerecht verarbeitet werden können. Die gängigsten Szenarien sind das Blockieren von Aufrufen über asynchronen Code im Anwendungscode.

Lösung

Die Clientanwendung, die das SDK verwendet, sollte entsprechend skaliert werden.

Die Verfügbarkeit des Sockets oder Ports ist möglicherweise gering.

Bei Ausführung in Azure kann es auf Clients, die das .NET SDK verwenden, zur Azure SNAT-Portauslastung (PAT) kommen.

Lösung 1

Bei Ausführung auf Azure-VMs folgen Sie dem Leitfaden für die SNAT-Portauslastung.

Lösung 2

Bei Ausführung im Azure App Service folgen Sie dem Leitfaden zur Problembehandlung bei Verbindungsfehlern, und verwenden Sie die App Service-Diagnose.

Lösung 3

Bei Ausführung in Azure Functions müssen Sie der Azure Functions-Empfehlung zur Wartung von Singleton-Clients oder statischen Clients für alle beteiligten Dienste (einschließlich Azure Cosmos DB) folgen. Überprüfen Sie die Diensteinschränkungen basierend auf Typ und Größe Ihres Funktions-App-Hostings.

Lösung 4

Wenn Sie einen HTTP-Proxy verwenden, vergewissern Sie sich, dass er die Anzahl von Verbindungen unterstützt, die in ConnectionPolicy des SDK konfiguriert ist. Andernfalls werden Verbindungsprobleme auftreten.

Erstellen mehrerer Clientinstanzen

Das Erstellen mehrerer Clientinstanzen kann zu Verbindungskonflikten und Timeoutproblemen führen. Die Diagnose enthält zwei relevante Eigenschaften:

{
    "NumberOfClientsCreated":X,
    "NumberOfActiveClients":Y,
}

NumberOfClientsCreated verfolgt die Anzahl, wie oft ein CosmosClient innerhalb derselben AppDomain erstellt wurde und NumberOfActiveClients verfolgt die aktiven Clients (nicht verworfen). Es wird erwartet, wenn das Singleton-Muster befolgt wird, stimmt X mit der Anzahl der Konten überein, mit denen die Anwendung arbeitet und X ist gleich Y.

Wenn X größer als Y ist, bedeutet dies, dass die Anwendung Clientinstanzen erstellt und entfernt. Dies kann zu Verbindungskonflikten und/oder CPU-Konflikten führen.

Lösung

Befolgen Sie die Leistungstipps, und verwenden Sie eine einzige CosmosClient-Instanz pro Konto für den gesamten Prozess. Vermeiden Sie das Erstellen und Entfernen von Clients.

Partitionsschlüssel auf heißer Ebene

Azure Cosmos DB verteilt den gesamten bereitgestellten Durchsatz gleichmäßig auf die physischen Partitionen. Wenn es eine heiße Partition gibt, werden alle Anforderungseinheiten pro Sekunde (RU/s) einer physischen Partition von einem logischen Partitionsschlüssel (oder mehreren logischen Partitionsschlüsseln) darauf verbraucht. Gleichzeitig werden die RU/s auf anderen physischen Partitionen nicht genutzt. Die insgesamt genutzten RU/s sind weniger als die insgesamt bereitgestellten RU/s in der Datenbank oder im Container. Anforderungen für den logischen Partitionsschlüssel auf heißer Ebene werden jedoch weiterhin gedrosselt (429s). Im Artikel Überwachen von normalisierten RU/s für einen Azure Cosmos-Container oder ein -Konto finden Sie weitere Informationen, wie Sie erfahren, ob die Workload Probleme mit der Partition auf heißer Ebene hat.

Lösung

Wählen Sie einen geeigneten Partitionsschlüssel aus, der Anforderungsvolume und -speicher gleichmäßig verteilt. Weitere Informationen finden Sie unter Ändern des Partitionsschlüssels in Azure Cosmos DB.

Hoher Parallelitätsgrad

Die Anwendung weist einen hohen Parallelitätsgrad auf. Das kann zu Konflikten im Kanal führen.

Lösung

Die Clientanwendung, die das SDK verwendet, sollte entsprechend skaliert werden.

Große Anforderungen oder Antworten

Große Anforderungen oder Antworten können zu Head-of-Line-Blockierungen im Kanal führen und die Konfliktsituation verschärfen, selbst bei einem relativ geringen Grad an Parallelität.

Lösung

Die Clientanwendung, die das SDK verwendet, sollte entsprechend skaliert werden.

Die Fehlerrate liegt innerhalb der Azure Cosmos DB SLA (Service Level Agreement, Vereinbarung zum Servicelevel).

Die Anwendung sollte vorübergehende Fehler verarbeiten können und bei Bedarf wiederholte Versuche ausführen. Bei 408-Ausnahmen wird kein wiederholter Versuch ausgeführt, weil es bei Erstellpfaden nicht möglich ist zu wissen, ob der Dienst das Element erstellt hat oder nicht. Wenn dasselbe Element noch mal für einen Erstellvorgang gesendet wird, führt dies zu einer Konfliktausnahme. In der Geschäftslogik von Benutzeranwendungen ist möglicherweise eine benutzerdefinierte Logik zur Verarbeitung von Konflikten enthalten. Dabei würde aufgrund der Mehrdeutigkeit eines vorhandenen Elements und dem Konflikt aus einem wiederholten Erstellversuch ein Fehler auftreten.

Fehlerrate verstößt gegen die Azure Cosmos DB SLA

Wenden Sie sich an den Azure-Support.

Nächste Schritte