3- Kontolimits wurden überschritten - Amazon-DynamoDB
Das Kontolimit hat die Minderungsmaßnahmen überschrittenAllgemeine Diagnose und ÜberwachungLösungsverfahren

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.

3- Kontolimits wurden überschritten

Für On-Demand-Tabellen gibt es keine bereitgestellten Kapazitätsstufen, die verwaltet werden müssen, aber DynamoDB setzt Durchsatzbegrenzungen auf Kontoebene durch, um eine unkontrollierte Ausführung zu verhindern und eine faire Ressourcennutzung für alle Kunden sicherzustellen. Diese Kontolimits pro Tabelle dienen als einstellbare Sicherheitsvorkehrungen, die für jede Kombination aus Konto und Region festgelegt werden. Wenn Ihre Lese- oder Schreibverbrauchsrate diese Grenzwerte überschreitet, gibt DynamoDB in der AccountLimitExceeded Drosselungsausnahme einen Einschränkungsgrundtyp zurück. Die standardmäßigen Kontogrenzwerte pro Tabelle gelten automatisch, wenn für Tabellen keine benutzerdefinierten Einstellungen für den maximalen Durchsatz konfiguriert sind. Sie können optional die Einstellungen für den maximalen Durchsatz konfigurieren, um die Kosten besser kontrollieren und besser vorhersagen zu können, oder über die Kontingente in Amazon DynamoDB Konsole Kontingenterhöhungen anfordern, falls Ihre Anwendungsanforderungen die Standardgrenzwerte überschreiten.

Das Kontolimit hat die Minderungsmaßnahmen überschritten

In diesem Abschnitt finden Sie Anleitungen zur Lösung von Szenarien mit der Drosselung von Kontolimits. Bevor Sie dieses Handbuch verwenden, stellen Sie sicher, dass Sie die spezifischen Drosselungsgründe anhand der Ausnahmebehandlung Ihrer Anwendung identifiziert und den Amazon-Ressourcennamen (ARN) der betroffenen Ressource ermittelt haben. Informationen zum Abrufen der Gründe für die Drosselung und zur Identifizierung gedrosselter Ressourcen finden Sie unter. DynamoDB-Drosselungsdiagnose-Framework

Bevor Sie sich mit bestimmten Drosselungsszenarien befassen, sollten Sie zunächst feststellen, ob tatsächlich Maßnahmen erforderlich sind:

  • Beurteilen Sie die Auswirkungen auf die Leistung: Prüfen Sie, ob Ihre Anwendung trotz der Drosselung immer noch die Leistungsanforderungen erfüllt. Viele Anwendungen laufen erfolgreich an oder nahe den Kontogrenzen, insbesondere bei Massenoperationen oder Datenmigrationen.

  • Überprüfen Sie die Drosselungsmuster: Wenn die Drosselung nur sporadisch erfolgt und Ihre Anwendung Wiederholungsversuche effektiv verarbeitet, können die aktuellen Grenzwerte für Ihre Arbeitslast ausreichend sein.

Wenn Ihre Anwendung auch bei gelegentlichem Überschreiten der Kontogrenzen eine akzeptable Leistung erbringt, können Sie sich dafür entscheiden, die Situation einfach zu überwachen, anstatt sofortige Änderungen vorzunehmen.

Wenn Sie feststellen, dass die Drosselung zu inakzeptablen Leistungsproblemen oder Zuverlässigkeitsproblemen führt, wählen Sie unten einen bestimmten Drosselungsgrund aus, um die empfohlenen Abhilfemaßnahmen zu finden:

TableReadAccountLimitExceeded

Wenn das passiert

Der Leseverbrauch Ihrer Tabelle hat das Kontingent für den Lesedurchsatz pro Tabelle auf Kontoebene für Ihre Region überschritten. Sie können die CloudWatch Messwerte überwachen, um Ihr Allgemeine Diagnose und Überwachung Drosselungsereignis zu analysieren.

Lösungsansatz

Gehen Sie wie folgt vor, um diese Drosselung zu beheben:

  • Erhöhung des Kontingents beantragen:

    Beantragen Sie eine Erhöhung des Grenzwerts für den Lesedurchsatz pro Tabelle (Quotencode L-CF0CBE56). Eine ausführliche Anleitung zum Einreichen der Anfrage finden Sie unter Eine Erhöhung des Kontingents pro Tabelle beantragen.

TableWriteAccountLimitExceeded

Wenn das passiert

Der Schreibverbrauch Ihrer Tabelle hat den Schreibdurchsatz pro Tabelle auf Kontoebene für Ihre Region überschritten. Sie können die CloudWatch Messwerte überwachen, um Ihr Allgemeine Diagnose und Überwachung Drosselungsereignis zu analysieren.

Lösungsansatz

Gehen Sie wie folgt vor, um diese Drosselung zu beheben:

  • Erhöhung des Kontingents anfordern: Fordern Sie eine Erhöhung des Schreibdurchsatzlimits pro Tabelle an (Quotencode L-). AB614373 Eine ausführliche Anleitung zum Einreichen der Anfrage finden Sie unter Eine Erhöhung der Quote pro Tabelle beantragen.

IndexReadAccountLimitExceeded

Wenn das passiert

Die Lesevorgänge, die auf einen Global Secondary Index (GSI) abzielen, verbrauchen mehr Durchsatz, als das Lesekontingent Ihres Kontos pro Tabelle in Ihrer aktuellen AWS Region zulässt. Die Quote für den Lesedurchsatz pro Tabelle auf Kontoebene gilt zusammen für eine Tabelle und die gesamte Tabelle zusammen. GSIs Sie können die CloudWatch Messwerte überwachen, um Ihr Allgemeine Diagnose und Überwachung Drosselungsereignis zu analysieren.

Lösungsansatz

Wählen Sie die passende Lösung auf der Grundlage der Kapazitätsverteilung Ihres Kontos:

  • Erhöhung des Kontingents beantragen: Beantragen Sie eine Erhöhung des Grenzwerts für den Lesedurchsatz pro Tabelle (Kontingentcode L-CF0CBE56). Eine ausführliche Anleitung zum Einreichen der Anfrage finden Sie unter Eine Erhöhung des Kontingents pro Tabelle beantragen.

  • Optimieren Sie die GSI-Nutzung: Überprüfen Sie den GSI-Entwurf und die Abfragemuster, um unnötigen Lesekapazitätsverbrauch zu reduzieren.

IndexWriteAccountLimitExceeded

Wenn das passiert

Schreibvorgänge in Ihre Basistabelle führen zu entsprechenden Aktualisierungen für einen globalen Index, die zusammen die Quote für den Schreibdurchsatz pro Tabelle auf Kontoebene für Ihre Region überschreiten. AWS Jeder Schreibvorgang in ein Basistabellenelement, das Attribute enthält, die von einem globalen Index indexiert wurden, löst einen entsprechenden Schreibvorgang für diesen globalen Index aus. Diese kombinierten Schreibvorgänge werden auf Ihr Schreibdurchsatzkontingent pro Tabelle angerechnet. Sie können die CloudWatch Messwerte überwachenAllgemeine Diagnose und Überwachung, um die Muster und den Zeitpunkt dieser Drosselungsereignisse zu analysieren und festzustellen, welche Operationen die übermäßige GSI-Schreibaktivität verursachen.

Lösungsansatz

Wählen Sie die passende Lösung auf der Grundlage der Kapazitätsverteilung Ihres Kontos:

Allgemeine Diagnose und Überwachung

Wenn bei der Fehlerbehebung das Kontenlimit die Drosselung überschritten hat, können Sie anhand verschiedener CloudWatch Messwerte ermitteln, ob Sie die Grenzwerte pro Tabelle oder für das gesamte Konto überschreiten, und Ihre Kapazitätsverteilungsmuster besser nachvollziehen.

CloudWatch Wesentliche Messwerte

Überwachen Sie diese wichtigen Kennzahlen, um die Drosselung von Kontolimits zu diagnostizieren:

Lösungsverfahren

Eine Erhöhung der Quote pro Tabelle beantragen

Wenn Ihre Anwendungen die aktuellen Durchsatzgrenzen pro Tabelle überschreiten müssen, sollten Sie mit dem unten angegebenen Verfahren einen Antrag auf Erhöhung des Kontingents stellen. Jede DynamoDB-Tabelle in Ihrem AWS Konto (zusammen mit allen zugehörigen Tabellen GSIs) unterliegt diesen Durchsatzquoten innerhalb einer bestimmten Region. Diese Kontingente stellen die maximale Lese- oder Schreibkapazität dar, die eine einzelne Tabelle zusammen verbrauchen GSIs kann, und sie gelten unabhängig für jede Tabelle und nicht als Summe für alle Tabellen in Ihrem Konto.

Optional können Sie auch niedrigere Grenzwerte pro Tabelle oder pro GSI festlegen, indem Sie die Einstellungen für den maximalen On-Demand-Durchsatz konfigurieren.

  1. Identifizieren Sie das spezifische Kontingent, das erhöht werden muss:

    • Limit für den Lesedurchsatz pro Tabelle (Quotencode L-CF0CBE56): Standardmäßig 40.000 pro Tabelle RCUs

    • Grenzwert für den Schreibdurchsatz pro Tabelle (Quota-Code L-AB614373): Standardmäßig 40.000 pro Tabelle WCUs

  2. Verwenden Sie die AWS Service Quotas Quota-Konsole, um eine Erhöhung anzufordern:

    • Navigieren Sie in Service Quotas zum DynamoDB-Dienst

    • Suchen Sie mithilfe des Kontingentcodes nach dem entsprechenden Kontingent

    • Fordern Sie eine Erhöhung auf der Grundlage Ihrer voraussichtlichen Spitzennutzung an

  3. Begründen Sie die Erhöhung, einschließlich:

    • Aktuelle Nutzungsmuster und Anforderungen an den Spitzenverkehr

    • Geschäftliche Begründung für die Kapazitätserhöhung

    • Zeitplan für den Zeitpunkt, zu dem die erhöhte Kapazität benötigt wird

Anmerkung

Die Bearbeitung von Quotenerhöhungen dauert in der Regel 24-48 Stunden. Planen Sie Ihre Anfragen entsprechend und ziehen Sie vorübergehende Strategien zur Risikominderung in Betracht, während Sie auf die Genehmigung warten.

Optimierung der GSI-Prognosen und des Designs

Optimieren Sie Ihre Prognosen und Ihr Design für den Global Secondary Index (GSI), um den Kapazitätsverbrauch zu reduzieren und die Leistung zu verbessern.

Selektive Projektionsstrategien

Wenn Ihre Abfragen nur auf einige Attribute zugreifen müssen, reduziert die Projektion nur dieser Attribute die Datenmenge, die in den globalen Index geschrieben wird, wenn sich die Elemente der Basistabelle ändern. Einzelheiten zu Projektionstypen finden Sie unter Prognosen für globale Sekundärindizes.

  1. Analysieren Sie Abfragemuster: Überprüfen Sie die Abfragemuster Ihrer Anwendung, um festzustellen, auf welche Attribute tatsächlich über die GSI zugegriffen wird.

  2. Verwenden Sie selektive Prognosen: Projizieren Sie nur Attribute, die in Abfragen tatsächlich benötigt werden, um das Schreibvolumen zu reduzieren.

  3. Bedenken SieKEYS_ONLY: Wenn Ihre Abfragen nur die Schlüsselattribute benötigen, verwenden Sie KEYS_ONLY Projektion, um das Schreibvolumen zu minimieren.

  4. Abwägen zwischen Lese- und Schreibvorgängen: Die Projektion von weniger Attributen reduziert den Schreibkapazitätsverbrauch, erfordert jedoch möglicherweise zusätzliche Lesevorgänge in der Basistabelle.

Sparsame GSI-Implementierung

Sparse GSIs enthält nur Elemente, die das indizierte Attribut haben, und nicht alle Elemente aus Ihrer Basistabelle. Dadurch wird die Partitionsdichte reduziert und die Leistung verbessert, wenn Sie häufig bestimmte Teilmengen von Daten abfragen.

  1. Design GSIs , das nur Elemente mit bestimmten Attributwerten enthält.

  2. Implementieren Sie die bedingte Indizierung, indem Sie das Schlüsselattribut der GSI-Partition nur für Elemente festlegen, die indexiert werden sollen.

  3. Verwenden Sie zusammengesetzte Schlüssel mit geringer Dichte GSIs (z. B. status #timestamp), um den Verkehr innerhalb der Teilmenge der indizierten Elemente weiter zu verteilen.

Weitere Informationen zur Implementierung dieser Strategien finden Sie unter Bewährte Methoden für die Verwendung sekundärer Indizes in DynamoDB.