Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Wenn Ihre Anwendung Ihre bereitgestellte Durchsatzkapazität für eine Tabelle oder einen Index überschreitet, unterliegt sie der Anforderungsdrosselung. Durch das Drosseln wird verhindert, dass Ihre Anwendung zu viele Kapazitätseinheiten verbraucht. Wenn DynamoDB einen Lese- oder Schreibvorgang drosselt, gibt es a an den Aufrufer zurück. ProvisionedThroughputExceededException Die Anwendung kann anschließend die entsprechenden Maßnahmen ergreifen, z. B. auf ein kurzes Intervall zu warten, bevor die Anforderung wiederholt wird.
Bei der Behebung von Problemen, die offenbar mit der Drosselung zusammenhängen, besteht ein wichtiger erster Schritt darin, zu überprüfen, ob die Drosselung von DynamoDB oder von der Anwendung stammt.
In diesem Thema wird beschrieben, wie häufig auftretende Drosselungsprobleme im Modus „Bereitgestellte Kapazität“ behoben werden können. Im Folgenden werden einige gängige Szenarien und mögliche Schritte zu ihrer Behebung beschrieben.
Die DynamoDB-Tabelle scheint über ausreichend bereitgestellte Kapazität zu verfügen, aber Anfragen werden gedrosselt
Dies kann der Fall sein, wenn der Durchsatz unter dem Durchschnitt pro Minute liegt, aber die pro Sekunde verfügbare Menge übersteigt. DynamoDB meldet nur Metriken auf Minutenebene CloudWatch, die als Summe für eine Minute und als Durchschnittswert berechnet werden. DynamoDB selbst wendet jedoch Ratenlimits pro Sekunde an. Wenn der Durchsatz während eines kleinen Teils dieser Minute, beispielsweise während weniger Sekunden oder eines noch kürzeren Zeitraums, zu hoch ist, können Anforderungen für den Rest der betreffenden Minute gedrosselt werden.
Wenn wir beispielsweise 60 WCU für eine Tabelle bereitgestellt haben, können 3600 Schreibvorgänge in einer Minute ausgeführt werden. Wenn jedoch alle 3600 WCU-Anforderungen in derselben Sekunde eingehen, wird der Rest dieser Minute gedrosselt.
Eine Möglichkeit, dieses Problem zu lösen, kann darin bestehen, den API-Aufrufen Jitter und exponentielles Backoff hinzuzufügen. Weitere Informationen finden Sie in diesem Beitrag über Backoff und Jitter
Auto Scaling ist aktiviert, aber Tabellen werden immer noch gedrosselt
Dies kann bei plötzlichen Datenverkehrsspitzen passieren. Auto Scaling kann ausgelöst werden, wenn 2 Datenpunkte innerhalb einer Minute den konfigurierten Zielnutzungswert überschreiten. Daher kann Auto Scaling stattfinden, weil die verbrauchte Kapazität zwei Minuten lang über der Zielauslastung liegt. Wenn die Spitzen jedoch mehr als eine Minute voneinander entfernt sind, wird die auto Skalierung möglicherweise nicht ausgelöst.
In ähnlicher Weise kann eine Herunterskalierung ausgelöst werden, wenn 15 aufeinanderfolgende Datenpunkte unter der Zielauslastung liegen. In beiden Fällen wird nach dem Auslösen von Auto Scaling eine UpdateTable API-Operation aufgerufen. Es kann dann mehrere Minuten dauern, bis die bereitgestellte Kapazität für die Tabelle oder den Index aktualisiert ist. Während dieses Zeitraums werden alle Anfragen, die die zuvor bereitgestellte Kapazität der Tabellen überschreiten, gedrosselt.
Zusammenfassend lässt sich sagen, dass Auto Scaling aufeinanderfolgende Datenpunkte benötigt, an denen der Zielnutzungswert überschritten wird, um eine DynamoDB-Tabelle hochskalieren zu können. Aus diesem Grund wird Auto Scaling nicht als Lösung für den Umgang mit Spitzenlasten empfohlen. Weitere Informationen finden Sie in der Dokumentation zur Auto Scaling-Kostenoptimierung.
Ein Hotkey kann zu Drosselungsproblemen führen
In DynamoDB kann ein Partitionsschlüssel, der keine hohe Kardinalität aufweist, dazu führen, dass viele Anforderungen nur auf einige wenige Partitionen abzielen. Wenn eine resultierende heiße Partition die Partitionsgrenzen von 3000 RCU oder 1000 WCU pro Sekunde überschreitet, kann dies zu einer Drosselung führen. Das Diagnosetool CloudWatch Contributor Insights (CCI) kann beim Debuggen helfen, indem es CCI-Diagramme für die Zugriffsmuster der einzelnen Tabellenelemente bereitstellt. Sie können die Schlüssel, auf die am häufigsten zugegriffen wird, und andere Datenverkehrstrends Ihrer DynamoDB-Tabellen kontinuierlich überwachen. Weitere Informationen zu CloudWatch Contributor Insights finden Sie unter CloudWatch Contributor Insights for DynamoDB. Weitere Informationen finden Sie unter Entwerfen von Partitionsschlüsseln zur Verteilung Ihrer Arbeitslast in DynamoDB und Den richtigen DynamoDB-Partitionsschlüssel
Ihr Datenverkehr zur Tabelle überschreitet das Durchsatzkontingent auf Tabellenebene.
Die Kontingente für den Lese- und den Schreibdurchsatz auf Tabellenebene gelten auf Kontoebene in jeder Region. Diese Kontingente gelten für Tabellen im Modus bereitgestellter Kapazität und im On-Demand-Modus. Standardmäßig beträgt das für Ihre Tabelle festgelegte Durchsatzkontingent 40 000 Leseanforderungseinheiten und 40 000 Schreibanforderungseinheiten. Wenn der Datenverkehr zu Ihrer Tabelle dieses Kontingent überschreitet, wird die Tabelle möglicherweise gedrosselt. Weitere Informationen dazu, wie Sie dies verhindern können, finden Sie unter Überwachung von DynamoDB zur betrieblichen
Um dieses Problem zu beheben, verwenden Sie die Service-Quotas-Konsole, um das Lese- oder Schreibdurchsatz-Kontingent für Ihr Konto auf Tabellenebene zu erhöhen.
