Share via

Diagnose en roblemen oplossen met te hoge aanvraagsnelheid (429) van Azure Cosmos DB

  • Artikel

VAN TOEPASSING OP: NoSQL

Dit artikel bevat bekende oorzaken en oplossingen voor verschillende 429-statuscodefouten voor de API voor NoSQL. Als u de API voor MongoDB gebruikt, raadpleegt u het artikel Veelvoorkomende problemen in API voor MongoDB oplossen voor het opsporen van fouten in statuscode 16500.

Een uitzondering 'Aanvraagsnelheid is te groot', ook wel foutcode 429 genoemd, geeft aan dat uw aanvragen voor Azure Cosmos DB beperkt zijn.

Wanneer u ingerichte doorvoer gebruikt, stelt u de doorvoer in die wordt gemeten in aanvraageenheden per seconde (RU/s) die is vereist voor uw workload. Databasebewerkingen op basis van de service, zoals leesbewerkingen, schrijfbewerkingen en query's, verbruiken een aantal aanvraageenheden (RU's). Meer informatie over aanvraageenheden.

Als de bewerkingen in een bepaalde seconde meer verbruiken dan de ingerichte aanvraageenheden, retourneert Azure Cosmos DB een 429-uitzondering. Elke seconde is het aantal beschikbare aanvraageenheden opnieuw ingesteld.

Voordat u een actie onderneemt om de RU/s te wijzigen, is het belangrijk om de hoofdoorzaak van snelheidsbeperking te begrijpen en het onderliggende probleem op te lossen.

Tip

De richtlijnen in dit artikel zijn van toepassing op databases en containers met ingerichte doorvoer: zowel automatische schaalaanpassing als handmatige doorvoer.

Er zijn verschillende foutberichten die overeenkomen met verschillende typen 429 uitzonderingen:

Aanvraagsnelheid is groot

Dit is het meest voorkomende scenario. Dit gebeurt wanneer de aanvraageenheden die worden gebruikt door bewerkingen op gegevens het ingerichte aantal RU/s overschrijden. Als u handmatige doorvoer gebruikt, gebeurt dit wanneer u meer RU/s hebt verbruikt dan de handmatige doorvoer die is ingericht. Als u automatische schaalaanpassing gebruikt, gebeurt dit wanneer u meer hebt verbruikt dan het maximum aantal RU/s dat is ingericht. Als u bijvoorbeeld een resource hebt ingericht met handmatige doorvoer van 400 RU/s, ziet u 429 wanneer u meer dan 400 aanvraageenheden in één seconde verbruikt. Als u een resource hebt ingericht met maximale RU/s voor automatische schaalaanpassing van 4000 RU/s (schaalt tussen 400 RU/s - 4000 RU/s), ziet u 429 antwoorden wanneer u meer dan 4000 aanvraageenheden in één seconde verbruikt.

Tip

Alle bewerkingen worden in rekening gebracht op basis van het aantal resources dat ze verbruiken. Deze kosten worden gemeten in aanvraageenheden. Deze kosten omvatten aanvragen die niet zijn voltooid vanwege toepassingsfouten, zoals 400, 412449, enzovoort. Bij het bekijken van beperking of gebruik is het een goed idee om te onderzoeken of een bepaald patroon is gewijzigd in uw gebruik, wat zou leiden tot een toename van deze bewerkingen. Controleer met name op tags 412 of 449 (werkelijk conflict).

Zie ingerichte doorvoer in Azure Cosmos DB voor meer informatie over ingerichte doorvoer.

Stap 1: Controleer de metrische gegevens om het percentage aanvragen met 429-fout te bepalen

Het weergeven van 429-foutberichten betekent niet noodzakelijkerwijs dat er een probleem is met uw database of container. Een klein percentage van 429 antwoorden is normaal, ongeacht of u handmatige doorvoer of automatische schaalaanpassing gebruikt en een teken is dat u de RU/s die u hebt ingericht, maximaliseert.

Onderzoek doen

Bepaal welk percentage van uw aanvragen voor uw database of container heeft geresulteerd in 429 reacties, vergeleken met het totale aantal geslaagde aanvragen. Navigeer vanuit uw Azure Cosmos DB-account naar Insights>Requests Total Requests>by Status Code. Filteren op een specifieke database en container.

Standaard worden de SDK's en hulpprogramma's voor gegevensimport van de Azure Cosmos DB-client, zoals Azure Data Factory en de bulkexecutorbibliotheek, automatisch opnieuw geprobeerd op 429s. Ze proberen het meestal maximaal negen keer. Als gevolg hiervan worden mogelijk 429 antwoorden in de metrische gegevens weergegeven, maar deze fouten zijn mogelijk niet eens geretourneerd naar uw toepassing.

Totaal aantal aanvragen per statuscodediagram met het aantal 429- en 2xx-aanvragen.

Over het algemeen geldt dat voor een productieworkload, als u tussen 1-5% van de aanvragen met 429 antwoorden ziet en uw end-to-endlatentie acceptabel is, is dit een goed teken dat de RU/s volledig worden gebruikt. Er is geen actie vereist. Ga anders naar de volgende stappen voor probleemoplossing.

Belangrijk

Dit bereik van 1-5% gaat ervan uit dat uw accountpartities gelijkmatig worden verdeeld. Als uw partities niet gelijkmatig zijn verdeeld, kan uw probleempartitie een grote hoeveelheid 429-fouten retourneren terwijl de algehele snelheid laag is.

Als u automatische schaalaanpassing gebruikt, kunt u 429 antwoorden op uw database of container zien, zelfs als de RU/s niet zijn geschaald naar het maximum aantal RU/s. Zie de sectie Aanvraagsnelheid is groot met automatische schaalaanpassing voor een uitleg.

Een veelvoorkomende vraag is: 'Waarom zie ik 429 antwoorden in de metrische gegevens van Azure Monitor, maar geen in mijn eigen toepassingsbewaking?' Als azure Monitor Metrics laat zien dat u 429 antwoorden hebt, maar u er geen hebt gezien in uw eigen toepassing, komt dit omdat de SDK's automatically retried internally on the 429 responses van de Azure Cosmos DB-client en de aanvraag zijn geslaagd in volgende nieuwe pogingen. Als gevolg hiervan wordt de 429-statuscode niet geretourneerd naar de toepassing. In deze gevallen is de totale snelheid van 429 antwoorden doorgaans minimaal en kan veilig worden genegeerd, ervan uitgaande dat de algehele snelheid tussen 1 en 5% en end-to-end latentie acceptabel is voor uw toepassing.

Stap 2: Bepalen of er een dynamische partitie is

Er ontstaat een dynamische partitie wanneer een of enkele logische partitiesleutels een onevenredige hoeveelheid ru/s verbruiken vanwege een hoger aanvraagvolume. Dit kan worden veroorzaakt door een partitiesleutelontwerp dat geen aanvragen gelijkmatig distribueert. Dit resulteert in veel aanvragen die worden omgeleid naar een kleine subset van logische partities (wat fysieke) partities impliceert die 'dynamisch' worden. Omdat alle gegevens voor een logische partitie zich op één fysieke partitie bevinden en het totale aantal RU/s gelijkmatig wordt verdeeld over de fysieke partities, kan een dynamische partitie leiden tot 429 reacties en inefficiënt gebruik van doorvoer.

Hier volgen enkele voorbeelden van partitioneringsstrategieën die leiden tot dynamische partities:

  • U hebt een container die IoT-apparaatgegevens opslaat voor een schrijfintensieve workload die is gepartitioneerd door date. Alle gegevens voor één datum bevinden zich op dezelfde logische en fysieke partitie. Omdat alle gegevens die elke dag zijn geschreven dezelfde datum hebben, resulteert dit elke dag in een dynamische partitie.
    • In plaats daarvan zou voor dit scenario een partitiesleutel zoals id (een GUID of apparaat-id) of een synthetische partitiesleutel worden gecombineerd id en date een hogere kardinaliteit van waarden en een betere verdeling van het aanvraagvolume opleveren.
  • U hebt een scenario met meerdere tenants met een container die is gepartitioneerd door tenantId. Als één tenant veel actiever is dan de andere, resulteert dit in een dynamische partitie. Als de grootste tenant bijvoorbeeld 100.000 gebruikers heeft, maar de meeste tenants minder dan 10 gebruikers hebben, hebt u een dynamische partitie wanneer deze wordt gepartitioneerd door tenantID.
    • Voor dit vorige scenario kunt u overwegen om een toegewezen container voor de grootste tenant te hebben, gepartitioneerd door een meer gedetailleerde eigenschap, zoals UserId.

De dynamische partitie identificeren

Als u wilt controleren of er een dynamische partitie is, gaat u naar Genormaliseerd RU-verbruik voor inzichten>>(%) op PartitionKeyRangeID. Filteren op een specifieke database en container.

Elke PartitionKeyRangeId wordt toegewezen aan één fysieke partitie. Als er één PartitionKeyRangeId is met een veel hoger genormaliseerd RU-verbruik dan andere (een is bijvoorbeeld consistent op 100%, maar andere op 30% of minder), kan dit een teken zijn van een dynamische partitie. Meer informatie over de metrische gegevens voor genormaliseerd RU-verbruik.

Genormaliseerd RU-verbruik per PartitionKeyRangeId-grafiek met een dynamische partitie.

Als u wilt zien welke logische partitiesleutels de meeste RU/s gebruiken, gebruikt u diagnostische logboeken van Azure. Met deze voorbeeldquery worden de totale aanvraageenheden opgeteld die per seconde worden verbruikt op elke logische partitiesleutel.

Belangrijk

Voor het inschakelen van diagnostische logboeken worden afzonderlijke kosten in rekening gebracht voor de Log Analytics-service, die wordt gefactureerd op basis van het opgenomen gegevensvolume. U wordt aangeraden diagnostische logboeken gedurende een beperkte periode in te schakelen voor foutopsporing en uit te schakelen wanneer u deze niet meer nodig hebt. Zie de pagina met prijzen voor meer informatie.

 CDBPartitionKeyRUConsumption
 | where TimeGenerated >= ago(24hour)
 | where CollectionName == "CollectionName"
 | where isnotempty(PartitionKey)
 // Sum total request units consumed by logical partition key for each second
 | summarize sum(RequestCharge) by PartitionKey, OperationName, bin(TimeGenerated, 1s)
 | order by sum_RequestCharge desc

In deze voorbeelduitvoer ziet u dat in een bepaalde minuut de logische partitiesleutel met de waarde Contoso ongeveer 12.000 RU/s heeft verbruikt, terwijl de logische partitiesleutel met de waarde Fabrikam minder dan 600 RU/s verbruikt. Als dit patroon consistent was tijdens de periode waarin snelheidsbeperking plaatsvond, zou dit duiden op een dynamische partitie.

Logische partitiesleutels gebruiken de meeste aanvraageenheden per seconde.

Tip

In elke workload is er natuurlijke variatie in het aanvraagvolume tussen logische partities. U moet bepalen of de dynamische partitie wordt veroorzaakt door een fundamentele scheefheid vanwege de keuze van de partitiesleutel (waarvoor mogelijk het wijzigen van de sleutel vereist is) of tijdelijke piek vanwege natuurlijke variatie in workloadpatronen.

Bekijk de richtlijnen voor het kiezen van een goede partitiesleutel.

Als er sprake is van een hoog percentage van beperkte aanvragen en geen dynamische partitie:

Als er een hoog percentage van beperkte aanvragen is en er een onderliggende dynamische partitie is:

  • Voor de beste kosten en prestaties op de lange termijn kunt u overwegen om de partitiesleutel te wijzigen. De partitiesleutel kan niet worden bijgewerkt. Hiervoor moet u de gegevens migreren naar een nieuwe container met een andere partitiesleutel. Azure Cosmos DB ondersteunt hiervoor een hulpprogramma voor livegegevensmigratie.
  • Op korte termijn kunt u de totale RU/s van de resource tijdelijk verhogen om meer doorvoer naar de dynamische partitie toe te staan. Dit wordt niet aanbevolen als een langetermijnstrategie, omdat dit leidt tot overprovisioning van RU/s en hogere kosten.
  • Op korte termijn kunt u de doorvoerherdistributie tussen partities ( preview) gebruiken om meer RU/s toe te wijzen aan de fysieke partitie die dynamisch is. Dit wordt alleen aanbevolen wanneer de dynamische fysieke partitie voorspelbaar en consistent is.

Tip

Wanneer u de doorvoer verhoogt, wordt de schaalbewerking onmiddellijk voltooid of duurt het maximaal 5-6 uur, afhankelijk van het aantal RU/s dat u omhoog wilt schalen. Als u het hoogste aantal RU/s wilt weten dat u kunt instellen zonder de asynchrone schaalbewerking te activeren (waarvoor Azure Cosmos DB meer fysieke partities moet inrichten), vermenigvuldigt u het aantal afzonderlijke PartitionKeyRangeIds met 10.0000 RU/s. Als u bijvoorbeeld 30.000 RU/s hebt ingericht en 5 fysieke partities (6000 RU/s toegewezen per fysieke partitie), kunt u in een onmiddellijke schaalbewerking verhogen tot 50.000 RU/s (10.000 RU/s per fysieke partitie). Voor het verhogen van >50.000 RU/s is een asynchrone schaalbewerking vereist. Meer informatie over aanbevolen procedures voor het schalen van ingerichte doorvoer (RU/s).

Stap 3: bepalen welke aanvragen 429 antwoorden retourneren

Aanvragen onderzoeken met 429 antwoorden

Gebruik diagnostische logboeken van Azure om te bepalen welke aanvragen 429 antwoorden retourneren en hoeveel RU's ze hebben verbruikt. Deze voorbeeldquery wordt geaggregeerd op minuutniveau.

Belangrijk

Voor het inschakelen van diagnostische logboeken worden afzonderlijke kosten in rekening gebracht voor de Log Analytics-service, die wordt gefactureerd op basis van het aantal opgenomen gegevens. U wordt aangeraden diagnostische logboeken gedurende een beperkte hoeveelheid tijd in te schakelen voor foutopsporing en uit te schakelen wanneer u deze niet meer nodig hebt. Zie de pagina met prijzen voor meer informatie.

 CDBDataPlaneRequests
 | where TimeGenerated >= ago(24h)
 | summarize throttledOperations = dcountif(ActivityId, StatusCode == 429), totalOperations = dcount(ActivityId), totalConsumedRUPerMinute = sum(RequestCharge) by DatabaseName, CollectionName, OperationName, RequestResourceType, bin(TimeGenerated, 1min)
 | extend averageRUPerOperation = 1.0 * totalConsumedRUPerMinute / totalOperations
 | extend fractionOf429s = 1.0 * throttledOperations / totalOperations
 | order by fractionOf429s desc

In deze voorbeelduitvoer ziet u bijvoorbeeld dat elke minuut 30% van het maken van documentaanvragen beperkt was, waarbij elke aanvraag gemiddeld 17 RU's verbruikt. Aanvragen met 429 in diagnostische logboeken.

De Azure Cosmos DB-capaciteitsplanner gebruiken

U kunt de Azure Cosmos DB-capaciteitsplanner gebruiken om te begrijpen wat de beste ingerichte doorvoer is op basis van uw workload (volume en type bewerkingen en grootte van documenten). U kunt de berekeningen verder aanpassen door voorbeeldgegevens op te geven om een nauwkeurigere schatting te krijgen.

429 antwoorden bij het maken, vervangen of upsert van documentaanvragen
  • Standaard worden in de API voor NoSQL alle eigenschappen standaard geïndexeerd. Stem het indexeringsbeleid af om alleen de benodigde eigenschappen te indexeren. Hiermee verlaagt u de aanvraageenheden die nodig zijn per bewerking voor het maken van documenten, waardoor de kans op 429 reacties wordt verminderd of dat u hogere bewerkingen per seconde kunt uitvoeren voor dezelfde hoeveelheid ingerichte RU/s.
429 antwoorden op querydocumentaanvragen
429 reacties bij het uitvoeren van opgeslagen procedures
  • Opgeslagen procedures zijn bedoeld voor bewerkingen waarvoor schrijftransacties voor een partitiesleutelwaarde zijn vereist. Het wordt niet aanbevolen om opgeslagen procedures te gebruiken voor een groot aantal lees- of querybewerkingen. Voor de beste prestaties moeten deze lees- of querybewerkingen aan de clientzijde worden uitgevoerd met behulp van de Azure Cosmos DB SDK's.

Aanvraagsnelheid is groot met automatische schaalaanpassing

Alle richtlijnen in dit artikel zijn van toepassing op zowel handmatige als automatische schaalaanpassing van doorvoer.

Wanneer u automatische schaalaanpassing gebruikt, is een veelvoorkomende vraag die zich voordoet: 'Is het nog steeds mogelijk om 429 antwoorden te zien met automatische schaalaanpassing?'

Ja. Er zijn twee hoofdscenario's waarin dit kan gebeuren.

Scenario 1: Wanneer de totale verbruikte RU/s de maximale RU/s van de database of container overschrijdt, beperkt de service aanvragen dienovereenkomstig. Dit is vergelijkbaar met het overschrijden van de totale handmatig ingerichte doorvoer van een database of container.

Scenario 2: Als er een dynamische partitie is, is een logische partitiesleutelwaarde die een onevenredig hogere hoeveelheid aanvragen heeft dan andere partitiesleutelwaarden, het is mogelijk dat de onderliggende fysieke partitie het RU/s-budget overschrijdt. Als best practice om dynamische partities te voorkomen, kiest u een goede partitiesleutel die resulteert in een gelijkmatige verdeling van zowel opslag als doorvoer. Dit is vergelijkbaar met wanneer er een dynamische partitie is bij het gebruik van handmatige doorvoer.

Als u bijvoorbeeld de maximale doorvoeroptie 20.000 RU/s selecteert en 200 GB opslagruimte met vier fysieke partities hebt, kan elke fysieke partitie automatisch worden geschaald tot 5000 RU/s. Als er een dynamische partitie is op een bepaalde logische partitiesleutel, ziet u 429 antwoorden wanneer de onderliggende fysieke partitie waarin deze zich bevindt, groter is dan 5000 RU/s, dat wil gezegd, groter is dan 100% genormaliseerd gebruik.

Volg de richtlijnen in stap 1, stap 2 en stap 3 om fouten in deze scenario's op te sporen.

Een andere veelvoorkomende vraag is: Waarom is genormaliseerd RU-verbruik 100%, maar automatisch schalen is niet geschaald naar de maximale RU/s?

Dit gebeurt meestal voor workloads met tijdelijke of onregelmatige pieken in het gebruik. Wanneer u automatische schaalaanpassing gebruikt, schaalt Azure Cosmos DB de RU/s alleen naar de maximale doorvoer wanneer het genormaliseerde RU-verbruik 100% is voor een langdurige, continue periode in een interval van 5 seconden. Dit wordt gedaan om ervoor te zorgen dat de schaallogica kostenvriendelijk is voor de gebruiker, omdat het ervoor zorgt dat enkele tijdelijke pieken niet leiden tot onnodig schalen en hogere kosten. Wanneer er momentele pieken zijn, wordt het systeem meestal omhoog geschaald naar een waarde die hoger is dan de eerder geschaalde RU/s, maar lager is dan de maximale RU/s. Meer informatie over het interpreteren van de metrische gegevens voor genormaliseerd RU-verbruik met automatische schaalaanpassing.

Snelheidsbeperking voor metagegevensaanvragen

Snelheidsbeperking van metagegevens kan optreden wanneer u een groot aantal metagegevensbewerkingen uitvoert op databases en/of containers. Metagegevensbewerkingen zijn onder andere:

  • Een container of database maken, lezen, bijwerken of verwijderen
  • Databases of containers weergeven in een Azure Cosmos DB-account
  • Query's uitvoeren op aanbiedingen om de huidige ingerichte doorvoer te bekijken

Er is een door het systeem gereserveerde RU-limiet voor deze bewerkingen, dus het verhogen van de ingerichte RU/s van de database of container heeft geen invloed en wordt niet aanbevolen. Zie Servicelimieten voor besturingsvlak.

Onderzoek doen

Navigeer naar Insights>System>Metadata Requests By Status Code. Filter desgewenst op een specifieke database en container.

Metagegevensaanvragen per statuscodegrafiek in Insights.

  • Als uw toepassing metagegevensbewerkingen moet uitvoeren, kunt u overwegen een uitstelbeleid te implementeren om deze aanvragen met een lager tarief te verzenden.

  • Gebruik statische Azure Cosmos DB-clientinstanties. Wanneer de DocumentClient of CosmosClient wordt geïnitialiseerd, haalt de Azure Cosmos DB SDK metagegevens op over het account, inclusief informatie over het consistentieniveau, databases, containers, partities en aanbiedingen. Deze initialisatie kan een groot aantal RU's verbruiken en moet niet vaak worden uitgevoerd. Gebruik één DocumentClient-exemplaar en gebruik het voor de levensduur van uw toepassing.

  • Sla de namen van databases en containers in de cache op. Haal de namen van uw databases en containers op uit de configuratie of cache ze op het begin. Aanroepen zoals ReadDatabaseAsync/ReadDocumentCollectionAsync of CreateDatabaseQuery/CreateDocumentCollectionQuery resulteren in metagegevens aanroepen naar de service, die de door het systeem gereserveerde RU-limiet verbruiken. Deze bewerkingen moeten onregelmatig worden uitgevoerd.

Snelheidsbeperking vanwege tijdelijke servicefout

Deze 429-fout wordt geretourneerd wanneer de aanvraag een tijdelijke servicefout tegenkomt. Het verhogen van de RU/s op de database of container heeft geen invloed en wordt niet aanbevolen.

Probeer de aanvraag opnieuw. Als de fout enkele minuten blijft optreden, dient u een ondersteuningsticket in vanuit Azure Portal.

Volgende stappen