Freigeben über

Diagnose und Problembehandlung bei Java v4 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.

Schritte zur Problembehandlung

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

End-to-End-Timeout-Richtlinie

Es gibt Szenarien, in denen 408 Netzwerktimeoutfehler auftreten, auch wenn alle unten erwähnten vorab erwähnten Lösungen implementiert wurden. Eine allgemeine bewährte Methode zum Verringern der Taillatenz sowie zur Verbesserung der Verfügbarkeit in diesen Szenarien ist die Implementierung einer End-to-End-Timeout-Richtlinie. Die Taillatenz wird durch einen schnelleren Ausfall reduziert, und Anforderungseinheiten sowie clientseitige Berechnungskosten werden reduziert, indem Wiederholungsversuche nach dem Timeout beendet werden. Die Timeoutdauer kann auf CosmosItemRequestOptions festgelegt werden. Die Optionen können dann an jede Anforderung übergeben werden, die an Azure Cosmos DB gesendet wird:

CosmosEndToEndOperationLatencyPolicyConfig endToEndOperationLatencyPolicyConfig = new CosmosEndToEndOperationLatencyPolicyConfigBuilder(Duration.ofSeconds(1)).build();
CosmosItemRequestOptions options = new CosmosItemRequestOptions();
options.setCosmosEndToEndOperationLatencyPolicyConfig(endToEndOperationLatencyPolicyConfig);
container.readItem("id", new PartitionKey("pk"), options, TestObject.class);

Vorhandene Probleme

Wenn Sie feststellen, dass Anforderungen über längere Zeit nicht reagieren oder häufiger ein Timeout auftritt, führen Sie ein Upgrade des Java v4 SDK auf die neueste Version durch. HINWEIS: Wir empfehlen dringend, die Version 4.18.0 und höher zu verwenden. Weitere Informationen finden Sie in den Versionshinweisen zum Java v4 SDK.

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.

Lösung:

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

Verbindungsdrosselung

Eine Verbindungsdrosselung kann entweder aufgrund eines Verbindungslimit auf einem Hostcomputer oder aufgrund von Azure SNAT-Portauslastung (PAT) auftreten.

Verbindungslimit auf einem Hostcomputer

Bei einigen Linux-Systemen (beispielsweise Red Hat) gilt eine Obergrenze für die Gesamtzahl geöffneter Dateien. Da Sockets in Linux als Dateien implementiert werden, schränkt dies auch die Gesamtanzahl von Verbindungen ein. Führen Sie den folgenden Befehl aus.

ulimit -a

Lösung:

Die maximal zulässige Anzahl geöffneter Dateien, die als „nofile“ angegeben sind, muss mindestens 10.000 betragen. Weitere Informationen finden Sie im Artikel zu den Leistungstipps für das Azure Cosmos DB Java SDK v4.

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

Bei Ausführung in Azure kann es auf Clients, die das Java 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 GatewayConnectionConfig des SDK konfiguriert ist. Andernfalls werden Verbindungsprobleme auftreten.

Erstellen mehrerer Clientinstanzen

Das Erstellen mehrerer Clientinstanzen kann zu Verbindungskonflikten und Timeoutproblemen führen.

Lösung 1:

Befolgen Sie die Leistungstipps, und verwenden Sie eine einzige CosmosClient-Instanz für die gesamte Anwendung.

Lösung 2:

Wenn die Verwendung einer einzigen CosmosClient-Instanz in einer Anwendung nicht möglich ist, sollte eine gemeinsam genutzte Verbindung für mehrere Azure Cosmos DB-Clients über diese API connectionSharingAcrossClientsEnabled(true) in CosmosClient verwendet werden. Wenn Sie in derselben JVM über mehrere Instanzen von Azure Cosmos DB-Clients verfügen, die mit mehreren Azure Cosmos DB-Konten interagieren, ermöglicht dies eine gemeinsam genutzte Verbindung im Direktmodus, sofern dies zwischen Instanzen von Azure Cosmos DB-Clients möglich ist. Beachten Sie, dass bei Festlegen dieser Option die Verbindungskonfiguration (z. B. Sockettimeout-Konfiguration, Leerlauftimeout-Konfiguration) des ersten instanziierten Clients für alle anderen Clientinstanzen verwendet wird.

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