Diagnostizieren und Behandeln von Problemen mit Azure Cosmos DB für NoSQL Java v4 SDK-Anforderungstimeoutausnahmen

  • Gilt für:: ✅ NoSQL

Der HTTP 408-Fehler tritt auf, wenn das Software Development Kit (SDK) die Anforderung nicht vor dem Timeoutlimit abschließen konnte.

Schritte zur Fehlersuche

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-Netzwerk-Timeout-Fehler auftreten, auch wenn alle präventiven Lösungen hier implementiert sind. Eine allgemeine bewährte Methode zum Verringern der Taillatenz und zur Verbesserung der Verfügbarkeit in diesen Szenarien ist die Implementierung einer End-to-End-Timeout-Richtlinie. Die Taillatenz wird durch ein schnelleres Abbrechen reduziert, und die Anforderungseinheiten sowie die clientseitigen Berechnungskosten werden verringert, indem Wiederholungen nach dem Timeout beendet werden. Die Dauer des Timeouts kann auf CosmosItemRequestOptions festgelegt werden. Die Optionen können dann an jede Anforderung übergeben werden, die an Azure Cosmos DB für NoSQL 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 Anforderungen für längere Dauer hängen bleiben oder das Zeitlimit häufiger ausfallen, führen Sie ein Upgrade des Java v4 SDK auf die neueste Version durch. HINWEIS: Es wird dringend empfohlen, die Version 4.18.0 und höher zu verwenden. Weitere Details 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

Die Verbindungsdrosselung kann aufgrund einer Verbindungsbeschränkung auf einem Hostcomputer oder einer SNAT-Portausschöpfung (Azure Source Network Address Translation) auftreten.

Verbindungslimit auf einem Hostcomputer

Einige Linux-Systeme, z. B. Red Hat, haben eine obere Grenze für die Gesamtanzahl der geöffneten Dateien. Sockets in Linux werden als Dateien implementiert, sodass diese Zahl auch die Gesamtanzahl der Verbindungen einschränkt. Führen Sie den folgenden Befehl aus:

ulimit -a

Lösung

Die Anzahl der maximal zulässigen geöffneten Dateien, die als nofileidentifiziert werden, muss mindestens 10.000 oder mehr sein. Weitere Informationen finden Sie in den Leistungstipps des Azure Cosmos DB für NoSQL Java SDK v4.

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

Wenn Ihre Lösung in Azure ausgeführt wird, können Clients, die das Java SDK verwenden, die Azure SNAT-Portausschöpfung erreichen.

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 for NoSQL) 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 treten Verbindungsprobleme auf.

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 einzelne CosmosClient-Instanz in einer gesamten Anwendung.

Lösung 2

Wenn Singleton CosmosClient in einer Anwendung nicht möglich ist, empfehlen wir die Verwendung der Verbindungsfreigabe über mehrere Azure Cosmos DB für NoSQL-Clients über diese API connectionSharingAcrossClientsEnabled(true) in CosmosClient. Wenn Mehrere Instanzen des Clients mit mehreren Konten interagieren, ermöglicht die Aktivierung dieser Einstellung die Verbindungsfreigabe im direkten Modus. Dieser Modus ist nur aktiviert, wenn die Verbindungsfreigabe zwischen Instanzen von Azure Cosmos DB für NoSQL-Clients möglich ist. Beachten Sie, dass beim Festlegen dieser Freigabeoption die Verbindungskonfiguration (z. B. Socket-Timeout-Konfiguration, Leerlauf-Timeout-Konfiguration) des ersten instanziierten Clients für alle anderen Clientinstanzen verwendet werden.

Hot-Partitionierungsschlüssel

Azure Cosmos DB for NoSQL 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. Als Symptom sind die insgesamt verbrauchten RU/s niedriger als die insgesamt bereitgestellten RU/s in der Datenbank oder im Container, aber es treten weiterhin Drosselungen (Fehler 429) auf bei Anfragen gegen den heißen logischen Partitionsschlüssel. Verwenden Sie die Metrik "Normalisierter RU-Verbrauch ", um festzustellen, ob die Workload auf eine heiße Partition trifft.

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 Vereinbarung zum Servicelevel (Service Level Agreement, SLA) von Azure Cosmos DB for NoSQL.

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. Das erneute Senden desselben Elements zum Erstellen führt zu einer Konflikt ausnahme. 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.

Die Fehlerrate verstößt gegen die SLA von Azure Cosmos DB for NoSQL

Wenden Sie sich an den Azure-Support.

Verwandte Inhalte

  • Last updated on