Time-outuitzonderingen voor Azure Cosmos DB Java v4 SDK-aanvragen vaststellen en oplossen
VAN TOEPASSING OP: NoSQL
HTTP-fout 408 treedt op als de SDK de aanvraag niet vóór de time-outlimiet heeft kunnen voltooien.
Stappen voor probleemoplossing
De volgende lijst bevat bekende oorzaken en oplossingen voor time-outuitzonderingen van aanvragen.
End-to-end time-outbeleid
Er zijn scenario's waarin 408-netwerktime-outfouten optreden, zelfs wanneer alle hierboven genoemde oplossingen zijn geïmplementeerd. Een algemene best practice voor het verminderen van tail-latentie en het verbeteren van de beschikbaarheid in deze scenario's is het implementeren van end-to-end time-outbeleid. Tail-latentie wordt verminderd door sneller te mislukken en aanvraageenheden en rekenkosten aan de clientzijde worden verlaagd door nieuwe pogingen na de time-out te stoppen. De time-outduur kan worden ingesteld op CosmosItemRequestOptions
. De opties kunnen vervolgens worden doorgegeven aan elke aanvraag die naar Azure Cosmos DB wordt verzonden:
CosmosEndToEndOperationLatencyPolicyConfig endToEndOperationLatencyPolicyConfig = new CosmosEndToEndOperationLatencyPolicyConfigBuilder(Duration.ofSeconds(1)).build();
CosmosItemRequestOptions options = new CosmosItemRequestOptions();
options.setCosmosEndToEndOperationLatencyPolicyConfig(endToEndOperationLatencyPolicyConfig);
container.readItem("id", new PartitionKey("pk"), options, TestObject.class);
Bestaande problemen
Als er aanvragen blijven hangen voor langere duur of vaker een time-out optreedt, moet u de Java v4 SDK upgraden naar de nieuwste versie. OPMERKING: We raden u ten zeerste aan om versie 4.18.0 en hoger te gebruiken. Bekijk de releaseopmerkingen voor Java v4 SDK voor meer informatie.
Hoog CPU-gebruik
Hoog CPU-gebruik is het meest voorkomende geval. Voor een optimale latentie moet het CPU-gebruik ongeveer veertig procent zijn. Gebruik 10 seconden als interval om het maximale (niet het gemiddelde) CPU-gebruik te bewaken. CPU-pieken komen vaker voor bij query's tussen partities, waarbij meerdere verbindingen voor één query tot stand gebracht kunnen worden.
Oplossing:
De clienttoepassing die gebruikmaakt van de SDK, moet dan omhoog of omlaag worden geschaald.
Verbindingsbeperking
Verbindingsbeperking kan optreden vanwege een verbindingslimiet op een hostcomputer of azure SNAT-poortuitputting (PAT).
Verbindingslimiet op een hostcomputer
Sommige Linux-systemen, zoals Red Hat, hebben een bovengrens voor het totale aantal geopende bestanden. Sockets in Linux worden geïmplementeerd als bestanden, dus dit aantal beperkt ook het totale aantal verbindingen. Voer de volgende opdracht uit.
ulimit -a
Oplossing:
Het aantal maximaal toegestane geopende bestanden, die worden geïdentificeerd als 'nofile', moet ten minste 10.000 of meer zijn. Zie de prestatietips voor Azure Cosmos DB Java SDK v4 voor meer informatie.
De beschikbaarheid van sockets of poorten is mogelijk laag
Bij uitvoering in Azure kunnen clients die de Java SDK gebruiken, de poortuitputting van Azure SNAT (PAT) raken.
Oplossing 1:
Als u azure-VM's gebruikt, volgt u de SNAT-poortuitputtingshandleiding.
Oplossing 2:
Als u op Azure-app Service werkt, volgt u de handleiding voor het oplossen van verbindingsproblemen en gebruikt u diagnostische gegevens van App Service.
Oplossing 3:
Als u azure Functions uitvoert, controleert u of u de Aanbeveling van Azure Functions volgt om singleton- of statische clients te onderhouden voor alle betrokken services (inclusief Azure Cosmos DB). Controleer de servicelimieten op basis van het type en de grootte van uw functie-app-hosting.
Oplossing 4:
Als u een HTTP-proxy gebruikt, moet u ervoor zorgen dat deze het aantal verbindingen ondersteunt dat is geconfigureerd in de SDK GatewayConnectionConfig
. Anders ondervindt u verbindingsproblemen.
Meerdere clientexemplaren maken
Het maken van meerdere clientinstanties kan leiden tot verbindingsproblemen en time-outproblemen.
Oplossing 1:
Volg de tips voor prestaties en gebruik één CosmosClient-exemplaar in een hele toepassing.
Oplossing 2:
Als singleton CosmosClient niet mogelijk is in een toepassing, raden we u aan om verbinding te delen tussen meerdere Azure Cosmos DB-clients via deze API connectionSharingAcrossClientsEnabled(true)
in CosmosClient.
Wanneer u meerdere exemplaren van De Azure Cosmos DB-client in dezelfde JVM gebruikt die communiceren met meerdere Azure Cosmos DB-accounts, kunt u verbindingen in de directe modus inschakelen, indien mogelijk tussen exemplaren van de Azure Cosmos DB-client. Houd er rekening mee dat bij het instellen van deze optie de verbindingsconfiguratie (bijvoorbeeld de time-outconfiguratie voor sockets, time-outconfiguratie voor inactiviteit) van de eerste geïnstantieerde client wordt gebruikt voor alle andere clientexemplaren.
Dynamische partitiesleutel
Azure Cosmos DB verdeelt de totale ingerichte doorvoer gelijkmatig over fysieke partities. Bij een dynamische partitie verbruiken een of meer logische partitiesleutels op een fysieke partitie alle aanvraageenheden per seconde (RU/s) van de fysieke partitie. Tegelijkertijd blijven de RU/s op andere fysieke partities ongebruikt. Als symptoom is het totale aantal verbruikte RU/s kleiner dan de totale ingerichte RU/s in de database of container, maar u ziet nog steeds beperking (429s) voor de aanvragen op basis van de dynamische logische partitiesleutel. Gebruik de metrische gegevens voor genormaliseerd RU-verbruik om te zien of de werkbelasting een dynamische partitie ondervindt.
Oplossing:
Kies een goede partitiesleutel waarmee het aanvraagvolume en de opslag gelijkmatig worden gedistribueerd. Meer informatie over het wijzigen van uw partitiesleutel.
Hoge mate van gelijktijdigheid
De toepassing voert een hoog gelijktijdigheidsniveau uit, wat kan leiden tot conflicten op het kanaal.
Oplossing:
De clienttoepassing die gebruikmaakt van de SDK, moet dan omhoog of omlaag worden geschaald.
Grote aanvragen of antwoorden
Grote aanvragen of antwoorden kunnen leiden tot een hoofd-of-lijnblokkering op het kanaal en verergeren conflicten, zelfs met een relatief lage mate van gelijktijdigheid.
Oplossing:
De clienttoepassing die gebruikmaakt van de SDK, moet dan omhoog of omlaag worden geschaald.
Foutpercentage valt binnen de SLA van Azure Cosmos DB
De toepassing moet tijdelijke fouten kunnen afhandelen en het opnieuw proberen wanneer dat nodig is. 408 uitzonderingen worden niet opnieuw geprobeerd omdat het bij het maken van paden onmogelijk is om te weten of de service het item heeft gemaakt of niet. Als u hetzelfde item opnieuw verzendt voor het maken, ontstaat er een conflict-uitzondering. Bedrijfslogica van gebruikerstoepassingen kan aangepaste logica hebben voor het afhandelen van conflicten, waardoor de dubbelzinnigheid van een bestaand item ten opzichte van een conflict bij het maken van een nieuwe poging wordt verbroken.
Foutpercentage schendt de SLA van Azure Cosmos DB
Neem contact op met de ondersteuning van Azure.
Volgende stappen
- Problemen vaststellen en oplossen wanneer u de Azure Cosmos DB Java v4 SDK gebruikt.
- Meer informatie over prestatierichtlijnen voor Java v4.