Diagnostizieren und Behandeln von Problemen im Zusammenhang mit der Azure Cosmos DB-Ausnahme „Zu hohe Anforderungsrate“ (429)

GILT FÜR: NoSQL

In diesem Artikel werden bekannte Ursachen und Lösungen für verschiedene Fehler mit dem Statuscode 429 für die API für NoSQL beschrieben. Wenn Sie die API für MongoDB verwenden, finden Sie im Artikel Behandeln häufiger Probleme in der Azure Cosmos DB-API für MongoDB Informationen zum Debuggen des Statuscodes 16500.

Die Ausnahme „Anforderungsrate zu groß“ mit Fehlercode 429 weist darauf hin, dass die Rate Ihrer Anforderungen an Azure Cosmos DB begrenzt wird.

Wenn Sie bereitgestellten Durchsatz nutzen, legen Sie den Durchsatz fest, der in Anforderungseinheiten pro Sekunde (Request Units per Second, RU/s) gemessen wird, die für Ihre Workload erforderlich sind. Für dienstbezogene Datenbankvorgänge, z. B. Lese-, Schreib- und Abfragevorgänge, wird eine bestimmte Anzahl von Anforderungseinheiten (Request Units, RUs) benötigt. Weitere Informationen zu Anforderungseinheiten

Wenn die Vorgänge in einer bestimmten Sekunde mehr als die bereitgestellten Anforderungseinheiten beanspruchen, gibt Azure Cosmos DB die Ausnahme 429 zurück. Die Anzahl der verfügbaren Anforderungseinheiten wird sekündlich zurückgesetzt.

Bevor Sie eine Aktion zum Ändern der RU/s vornehmen, müssen Sie zunächst die Grundursache der Ratenbegrenzung verstehen und dann das zugrunde liegende Problem beheben.

Es gibt verschiedene Fehlermeldungen, die verschiedenen Ausnahmen des Typs 429 entsprechen:

• Die Anforderungsrate ist groß. Möglicherweise sind weitere Anforderungseinheiten erforderlich, sodass keine Änderungen erfolgt sind.
• Die Anforderung wurde aufgrund einer hohen Rate von Metadatenanforderungen nicht abgeschlossen.
• Die Anforderung wurde aufgrund eines vorübergehenden Dienstfehlers nicht abgeschlossen.

Anforderungsrate ist hoch

Dies ist das häufigste Szenario. Es tritt auf, wenn die Anforderungseinheiten, die von Datenvorgängen beansprucht werden, die bereitgestellte Anzahl von RU/s überschreiten. Bei manuellem Durchsatz ist dies der Fall, wenn die verbrauchten RU/s den bereitgestellten manuellen Durchsatz überschreiten. Bei automatisch skaliertem Durchsatz tritt das Szenario auf, wenn Ihr Verbrauch die maximale Anzahl bereitgestellter RU/s überschreitet. Bei einer Ressource mit einem manuellen Durchsatz von 400 RU/s wird z. B. eine Ausnahme vom Typ 429 angezeigt, wenn Sie mehr als 400 Anforderungseinheiten in einer Sekunde verbrauchen. Bei einer Ressource mit einem automatisch skalierten Durchsatz von maximal 4.000 RU/s (Skalierung zwischen 400 und 4.000 RU/s), erhalten Sie eine Ausnahme mit dem Fehlercode 429, wenn Sie mehr als 4.000 Anforderungseinheiten in einer Sekunde verbrauchen.

Schritt 1: Überprüfen der Metriken, um den Prozentsatz der Anforderungen mit Fehlercode 429 zu ermitteln

Fehlermeldungen mit dem Code 429 bedeuten nicht zwangsläufig, dass ein Problem mit Ihrer Datenbank oder Ihrem Container vorliegt. Eine geringe Anzahl von Ausnahmen mit dem Fehlercode 429 ist sowohl beim manuellen als auch beim automatisch skalierten Durchsatz normal und weist darauf hin, dass Sie die bereitgestellten RU/s maximal nutzen.

Vorgehen bei der Untersuchung

Bestimmen Sie, welcher Prozentsatz Ihrer Anforderungen an Ihre Datenbank oder Ihren Container im Vergleich zur Gesamtanzahl erfolgreicher Anforderungen zum Fehler 429 geführt hat. Navigieren Sie von Ihrem Azure Cosmos DB-Konto aus zu Erkenntnisse>Anforderungen>Anforderungen gesamt nach Statuscode. Filtern Sie nach einer bestimmten Datenbank und einem bestimmten Container.

Die SDKs des Azure Cosmos DB-Clients und Datenimporttools wie Azure Data Factory und BulkExecutor-Bibliothek wiederholen beim Fehlercode 429 Anforderungen automatisch. In der Regel erfolgen neun Wiederholungsversuche. Daher kann es sein, dass für Metriken ein Fehler vom Typ 429 angezeigt wird, obwohl diese Fehler gar nicht an Ihre Anwendung zurückgegeben wurden.

Empfohlene Lösung

Im Allgemeinen gilt für eine Produktionsworkload Folgendes: Wenn 1–5 % der Anforderungen den Fehlercode 429 aufweisen und die End-to-End-Latenz akzeptabel ist, ist dies ein positives Zeichen dafür, dass die RU/s vollständig genutzt werden. Keine Aktion erforderlich. Fahren Sie andernfalls mit den nächsten Problembehandlungsschritten fort.

Bei der automatischen Skalierung erhalten Sie möglicherweise auch dann Ausnahmen vom Typ 429 für Ihre Datenbank bzw. Ihren Container, wenn die maximale Anzahl von RU/s gar nicht erreicht wurde. Eine Erklärung hierfür finden Sie im Abschnitt Die Anforderungsrate ist bei Verwendung von Autoskalierung hoch.

Eine häufig gestellte Frage lautet: „Warum werden Ausnahmen vom Typ 429 in den Azure Monitor-Metriken angezeigt, aber nicht in meiner eigenen Anwendungsüberwachung?“ Dies liegt daran, dass die Anforderung in den von der Eigenschaft automatically retried internally on the 429 responses des Client SDKs von Azure Cosmos DB standardmäßig ausgeführten internen Wiederholungsversuchen erfolgreich war. Daher wird der Statuscode 429 nicht an die Anwendung zurückgegeben. In diesen Fällen ist die Gesamtanzahl der Ausnahmen vom Typ 429 in der Regel sehr gering und kann einfach ignoriert werden. Dies gilt unter der Voraussetzung, dass die Gesamtrate zwischen 1–5 % liegt und die End-to-End-Latenz für Ihre Anwendung akzeptabel ist.

Schritt 2: Ermitteln, ob eine heiße Partition vorhanden ist

Es kommt zu einer heißen Partition, wenn mindestens ein logischer Partitionsschlüssel aufgrund eines höheren Anforderungsvolumens einen unverhältnismäßig großen Teil der gesamten RU/s beansprucht. Dies kann durch einen Partitionsschlüsselentwurf verursacht werden, aufgrund dessen Anforderungen nicht gleichmäßig verteilt werden. In diesem Fall werden viele Anforderungen an eine kleine Teilmenge logischer (physischer) Partitionen gerichtet, die „heiß“ werden. Da sich alle Daten für eine logische Partition auf einer physischen Partition befinden und die gesamten RU/s gleichmäßig auf die physischen Partitionen verteilt werden, kann eine heiße Partition zu Fehlern des Typs 429 und einer ineffizienten Durchsatznutzung führen.

Es folgen einige Beispiele für Partitionierungsstrategien, die zu heißen Partitionen führen:

• Sie verfügen über einen Container, der IoT-Gerätedaten für eine Workload mit hohem Schreibaufwand speichert, die nach date partitioniert ist. Alle Daten für ein einzelnes Datum befinden sich in derselben logischen und physischen Partition. Da alle täglich geschriebenen Daten das gleiche Datum haben, würde dies jeden Tag zu einer heißen Partition führen.
  • Stattdessen erzielt für dieses Szenario ein Partitionsschlüssel wie id (entweder GUID oder Geräte-ID) oder ein synthetischer Partitionsschlüssel, der id und date kombiniert, eine höhere Kardinalität der Werte und eine bessere Verteilung des Anforderungvolumens.
• Sie haben ein Szenario mit mehreren Mandanten und einem nach tenantId partitionierten Container. Ist ein Mandant deutlich aktiver als die anderen, führt dies zu einer heißen Partition. Wenn z. B. der größte Mandant 100.000 Benutzer umfasst, die meisten Mandanten aber weniger als 10 Benutzer aufweisen, tritt bei Partitionierung nach tenantID eine heiße Partition auf.
  • Erwägen Sie für dieses Szenario einen dedizierten Container für den größten Mandanten, der nach einer detaillierteren Eigenschaft wie UserId partitioniert ist.

Erkennen der heißen Partition

Um zu überprüfen, ob eine heiße Partition vorliegt, wechseln Sie zu Erkenntnisse>Durchsatz>Normalisierter RU-Verbrauch (%) nach PartitionKeyRangeID. Filtern Sie nach einer bestimmten Datenbank und einem bestimmten Container.

Jede PartitionKeyRangeId ist einer physischen Partition zugeordnet. Weist eine PartitionKeyRangeId einen deutlich höheren normalisierten RU-Verbrauch als die anderen auf (der z. B. konstant bei 100 % liegt, während andere Partitionen einen Wert von höchstens 30 % aufweisen), kann dies ein Zeichen für eine heiße Partition sein. Erfahren Sie mehr über die Metrik Normalisierter RU-Verbrauch.

In den Azure-Diagnoseprotokollen können Sie herausfinden, welche logischen Partitionsschlüssel die meisten RU/s beanspruchen. Diese Beispielabfrage summiert für jeden logischen Partitionsschlüssel die insgesamt beanspruchten Anforderungseinheiten pro Sekunde.

 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

 AzureDiagnostics
 | where TimeGenerated >= ago(24hour)
 | where Category == "PartitionKeyRUConsumption"
 | where collectionName_s == "CollectionName"
 | where isnotempty(partitionKey_s)
 // Sum total request units consumed by logical partition key for each second
 | summarize sum(todouble(requestCharge_s)) by partitionKey_s, operationType_s, bin(TimeGenerated, 1s)
 | order by sum_requestCharge_s desc

Diese Beispielausgabe zeigt, dass in einer bestimmten Minute der logische Partitionsschlüssel mit dem Wert „Contoso“ etwa 12.000 RU/s beansprucht hat, während der logische Partitionsschlüssel mit dem Wert „Fabrikam“ weniger als 600 RU/s benötigte. Wenn dieses Muster während des Zeitraums, in dem die Ratenbegrenzung auftrat, gleichbleibend war, deutet dies auf eine heiße Partition hin.

Empfohlene Lösung

Lesen Sie die Anleitung zur Auswahl eines geeigneten Partitionsschlüssels.

Wenn es einen hohen Prozentsatz an Anforderungen mit Ratenbegrenzung und keine heiße Partition gibt:

• Sie können mithilfe von Client-SDKs, Azure-Portal, PowerShell, CLI oder ARM-Vorlage die RU/s für die Datenbank oder den Container erhöhen. Halten Sie sich an die bewährten Methoden für das Skalieren des bereitgestellten Durchsatzes (RU/s), um den richtigen Durchsatz zu ermitteln, der festgelegt werden sollte.

Wenn es einen hohen Prozentsatz an Anforderungen mit Ratenbegrenzung und eine zugrunde liegende heiße Partition gibt:

• Langfristig sollten Sie aus Kosten- und Leistungsgründen das Ändern des Partitionsschlüssels erwägen. Weil der Partitionsschlüssel nicht direkt aktualisiert werden kann, müssen die Daten in einen neuen Container mit einem anderen Partitionsschlüssel migriert werden. Zu diesem Zweck unterstützt Azure Cosmos DB ein Tool für die Migration von Livedaten.
• Kurzfristig können Sie die gesamten RU/s der Ressource vorübergehend erhöhen, um der heißen Partition einen höheren Durchsatz zu ermöglichen. Dies wird nicht als langfristige Strategie empfohlen, da dies zu einer Überbereitstellung von RU/s und höheren Kosten führt.
• Kurzfristig können Sie das Feature „Umverteilung des Azure Cosmos DB-Durchsatzes auf mehrere Partitionen“ (Vorschau) verwenden, um der heißen physischen Partition weitere RU/s zuzuweisen. Dies wird nur empfohlen, wenn die heiße physische Partition vorhersagbar und konsistent ist.

Schritt 3: Bestimmen, welche Anforderungen den Fehlercode 429 zurückgeben

Untersuchen von Anforderungen mit Fehlercode 429

Ermitteln Sie mithilfe von Azure-Diagnoseprotokollen, welche Anforderungen den Fehlercode 429 zurückgeben und wie viele RUs sie verbraucht haben. Diese Beispielabfrage führt eine Aggregation auf Minutenebene durch.

 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

 AzureDiagnostics
 | where TimeGenerated >= ago(24h)
 | where Category == "DataPlaneRequests"
 | summarize throttledOperations = dcountif(activityId_g, statusCode_s == 429), totalOperations = dcount(activityId_g), totalConsumedRUPerMinute = sum(todouble(requestCharge_s)) by databaseName_s, collectionName_s, OperationName, requestResourceType_s, bin(TimeGenerated, 1min)
 | extend averageRUPerOperation = 1.0 * totalConsumedRUPerMinute / totalOperations
 | extend fractionOf429s = 1.0 * throttledOperations / totalOperations
 | order by fractionOf429s desc

Diese Beispielausgabe zeigt beispielsweise, dass jede Minute 30 % der Anforderungen zum Erstellen von Dokumenten einer Ratenbegrenzung unterlagen, wobei jede Anforderung durchschnittlich 17 RUs verbrauchte.

Empfohlene Lösung

Verwenden des Azure Cosmos DB-Kapazitätsplaners

Sie können mithilfe des Azure Cosmos DB-Kapazitätsplaners ermitteln, welcher Durchsatz auf der Grundlage Ihrer Workload (Anzahl und Art der Vorgänge und Größe der Dokumente) am besten bereitgestellt werden sollte. Sie können die Berechnungen weiter anpassen, indem Sie Beispieldaten bereitstellen, um eine genauere Schätzung zu erhalten.

Fehlercode 429 bei Anforderungen zum Erstellen, Ersetzen oder Aktualisieren/Einfügen (Upsert) von Dokumenten

• Standardmäßig sind in der API für NoSQL alle Eigenschaften indiziert. Optimieren Sie die Indizierungsrichtlinie so, dass nur die erforderlichen Eigenschaften indiziert werden. Dadurch wird die Anzahl der erforderlichen Anforderungseinheiten pro Dokumenterstellungsvorgang gesenkt, was die Wahrscheinlichkeit des Fehlercodes 429 verringert oder Ihnen ermöglicht, bei gleicher Menge an bereitgestellten RU/s mehr Vorgänge pro Sekunde zu erreichen.

Fehlercode 429 bei Anforderungen zum Abfragen von Dokumenten

• Befolgen Sie die Anleitung zur Problembehandlung bei Abfragen mit hoher RU-Gebühr.

Fehlercode 429 beim Ausführen gespeicherter Prozeduren

• Gespeicherte Prozeduren sind für Vorgänge vorgesehen, die Schreibtransaktionen über einen Partitionsschlüsselwert hinweg erfordern. Für eine große Anzahl von Lese- oder Abfragevorgängen werden gespeicherte Prozeduren nicht empfohlen. Um eine optimale Leistung zu erzielen, sollten diese Lese- oder Abfragevorgänge auf der Clientseite unter Verwendung der Azure Cosmos DB SDKs ausgeführt werden.

Die Anforderungsrate ist bei Verwendung von Autoskalierung hoch

Die in diesem Artikel beschriebenen Anleitungen gelten sowohl für manuellen als auch für automatisch skalierten Durchsatz.

Bei Verwendung der Autoskalierung lautet eine häufig gestellte Frage: „Werden auch bei einem automatisch skalierten Durchsatz Ausnahmen mit dem Fehlercode 429 angezeigt?“

Ja. Es gibt zwei Hauptszenarios, in denen dies möglich ist.

Szenario 1: Wenn die Gesamtanzahl der verbrauchten RU/s die maximalen RU/s der Datenbank oder des Containers überschreitet, drosselt der Dienst die Anforderungen dementsprechend. Dies entspricht der Überschreitung des manuell bereitgestellten Gesamtdurchsatzes einer Datenbank oder eines Containers.

Szenario 2: Bei einer heißen Partition (d. h. einem logischen Partitionsschlüsselwert, der im Vergleich zu anderen Partitionsschlüsselwerten eine unverhältnismäßig höhere Anzahl von Anforderungen aufweist) ist es möglich, dass die zugrunde liegende physische Partition ihr Budget von RU/s überschreitet. Um Hot-Partitionen zu vermeiden, ist es am besten, einen geeigneten Partitionsschlüssel auszuwählen, der zu einer gleichmäßigen Verteilung von Speicher und Durchsatz führt. Dies ähnelt der Vorgehensweise für eine heiße Partition bei Verwendung des manuellen Durchsatzes.

Wenn Sie z. B. die Option für einen maximalen Durchsatz von 20.000 RU/s auswählen und über 200 GB Speicherplatz mit vier physischen Partitionen verfügen, kann jede physische Partition automatisch auf bis zu 5.000 RU/s skaliert werden. Befindet sich auf einem bestimmten logischen Partitionsschlüssel eine heiße Partition, wird der Fehlercode 429 angezeigt, wenn die zugrunde liegende physische Partition 5.000 RU/s (d. h. eine normalisierte Auslastung von 100 %) überschreitet.

Führen Sie die in Schritt 1, Schritt 2 und Schritt 3 beschriebenen Schritte aus, um die Probleme für diese Szenarios zu beheben.

Eine weitere häufig gestellte Frage lautet: „Warum liegt der normalisierte RU-Verbrauch bei 100 %, während bei der Autoskalierung die maximale Anzahl von RU/s nicht erreicht wird?“

Dies gilt in der Regel für Workloads mit temporären oder periodischen Auslastungsspitzen. Bei Verwendung der Autoskalierung skaliert Azure Cosmos DB die RU/s nur auf den maximalen Durchsatz, wenn der normalisierte RU-Verbrauch für einen anhaltenden und kontinuierlichen Zeitraum in einem Intervall von fünf Sekunden bei 100 % liegt. Dadurch wird eine für den Benutzer kostengünstige Skalierungsstrategie sichergestellt und unnötige Skalierungen (verbunden mit höheren Kosten) bei einzelnen, kurzzeitigen Auslastungsspitzen vermieden. Bei kurzzeitigen Auslastungsspitzen skaliert das System in der Regel auf einen Wert hoch, der zwar oberhalb der zuvor skalierten RU/s, aber unterhalb der maximalen Anzahl liegt. Weitere Informationen finden Sie im Artikel Anzeigen der Metrik für normalisierten RU-Verbrauch.

Ratenbegrenzung für Metadatenanforderungen

Eine Ratenbegrenzung für Metadaten kann erfolgen, wenn Sie eine große Anzahl von Metadatenvorgängen auf Datenbanken und/oder Container anwenden. Es folgen verschiedene Metadatenvorgänge:

• Erstellen, Lesen, Aktualisieren oder Löschen eines Containers oder einer Datenbank
• Auflisten von Datenbanken oder Containern in einem Azure Cosmos DB-Konto
• Abfragen von Angeboten, um den aktuellen bereitgestellten Durchsatz einzusehen

Es gibt einen vom System reservierten RU-Grenzwert für diese Vorgänge, sodass eine Erhöhung der für die Datenbank oder den Container bereitgestellten RU/s keine Auswirkungen hat und nicht empfohlen wird. Weitere Informationen finden Sie unter Grenzwerte auf Steuerungsebene.

Vorgehen bei der Untersuchung

Navigieren Sie zu Erkenntnisse>System>Metadatenanforderungen nach Statuscode. Filtern Sie nach Wunsch nach einer bestimmten Datenbank und einem bestimmten Container.

Empfohlene Lösung

• Wenn für Ihre Anwendung Metadatenvorgänge erforderlich sind, erwägen Sie die Implementierung einer Backoffrichtlinie, um diese Anforderungen mit einer niedrigeren Rate zu senden.

• Verwenden Sie statische Cosmos DB-Clientinstanzen. Wenn „DocumentClient“ oder „CosmosClient“ initialisiert wird, ruft das Azure Cosmos DB SDK Metadaten zum Konto ab, einschließlich Informationen zu Konsistenzebene, Datenbanken, Containern, Partitionen und Angeboten. Diese Initialisierung verbraucht unter Umständen eine hohe Anzahl von RUs und sollte daher nur selten ausgeführt werden. Verwenden Sie eine einzelne DocumentClient-Instanz, und nutzen Sie sie während der Lebensdauer Ihrer Anwendung.

• Speichern Sie die Namen von Datenbanken und Containern zwischen. Rufen Sie die Namen Ihrer Datenbanken und Container aus der Konfiguration ab, oder speichern Sie sie beim Starten zwischen. Aufrufe wie ReadDatabaseAsync/ReadDocumentCollectionAsync oder CreateDatabaseQuery/CreateDocumentCollectionQuery führen zu Metadatenaufrufen an den Dienst, die das vom System reservierte RU-Limit verbrauchen. Diese Vorgänge sollten selten erfolgen.

Ratenbegrenzung aufgrund eines vorübergehenden Dienstfehlers

Dieser Fehlercode 429 wird zurückgegeben, wenn bei der Anforderung ein vorübergehender Dienstfehler auftritt. Die Erhöhung der RU/s für Datenbank oder Container ist wirkungslos und wird nicht empfohlen.

Empfohlene Lösung

Wiederholen Sie die Anforderung. Wenn der Fehler mehrere Minuten bestehen bleibt, reichen Sie im Azure-Portal ein Supportticket ein.

Nächste Schritte

• Überwachen Sie den normalisierten RU/s-Verbrauch Ihrer Datenbank oder Ihres Containers.
• Diagnostizieren und Behandeln von Problemen bei Verwendung des .NET SDK für Azure Cosmos DB
• Weitere Informationen zu Leistungsrichtlinien für .NET Version 3 und .NET Version 2
• Diagnostizieren und Behandeln von Problemen bei Verwendung des Java v4 SDK für Azure Cosmos DB.
• Weitere Informationen zu Leistungsrichtlinien für das Java v4 SDK.