View a markdown version of this page

Drosselungsdiagnose - Amazon DynamoDB
Übersicht über DrosselungsausnahmenDiagnose-Framework

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.

Drosselungsdiagnose

Wenn Ihre Anwendung gedrosselt wird, bietet DynamoDB detaillierte Ausnahmeinformationen und gezielte CloudWatch Metriken, die Ihnen bei der Diagnose dieser Ereignisse helfen.

In diesem Abschnitt wird ein systematischer Ansatz zum Verständnis von Drosselungsereignissen in Ihren DynamoDB-Anwendungen vorgestellt. Es zeigt, wie Sie Drosselungsausnahmen interpretieren, sie mit CloudWatch Metriken korrelieren, um tiefere Einblicke zu erhalten und zu verstehen, welche Änderungen die Drosselung in Ihren DynamoDB-Anwendungen reduzieren würden.

Übersicht über Drosselungsausnahmen

Wenn DynamoDB eine Anfrage drosselt, gibt es spezifische Ausnahmen mit detaillierten Diagnoseinformationen zurück. In Java gehören dazu beispielsweise ProvisionedThroughputExceededException, RequestLimitExceeded oder ThrottlingException.

Jede Ausnahme umfasst ThrottlingReasons, eine Reihe einzelner ThrottlingReason mit zwei Schlüsselfeldern, mit deren Hilfe Sie Drosselungen identifizieren und verstehen können:

  • ein Grund – ein verkettetes Feld mit dem Format <ResourceType><OperationType><LimitType>

  • ein Amazon-Ressourcenname (ARN) – der Amazon-Ressourcenname (ARN) der betroffenen Tabelle oder des betroffenen Indexes

Das Feld mit dem Grund folgt einem konsistenten Muster, das Ihnen hilft, das Ereignis genau zu verstehen:

  • ResourceType(Was wird gedrosselt): oder Table Index

  • OperationType(Welche Art von Operation): oder Read Write

  • LimitType(Warum ist die Drosselung aufgetreten):

    • KeyRangeThroughputExceeded: Dies tritt auf, wenn eine bestimmte Partition, die Ihrer Tabelle oder Ihrem Index zugrunde liegt, Lese- oder Schreibkapazität verbraucht hat, die die internen Durchsatzlimits pro Partition überschreitet.

    • ProvisionedThroughputExceeded: Dies passiert bei einer bereitgestellten Tabelle oder einem bereitgestellten globalen sekundären Index, wenn die Lese- oder Schreibverbrauchsrate die bereitgestellte Menge überschritten hat.

    • AccountLimitExceeded: Dies passiert bei einer On-Demand-Tabelle oder einem On-Demand-Index, wenn die Lese- oder Schreibverbrauchsrate die auf Kontoebene festgelegte maximale Verbrauchsrate für eine Tabelle und ihre Indizes überschritten hat. Sie können eine Erhöhung dieses Kontingents anfordern.

    • MaxOnDemandThroughputExceeded: Dies passiert bei einer On-Demand-Tabelle oder einem On-Demand-Index, wenn die Lese- oder Schreibverbrauchsrate die vom Nutzer konfigurierte maximale Verbrauchsrate für die Tabelle und den Index überschritten hat. Sie können diesen Wert selbst auf einen beliebigen Wert bis zum Kontolimit erhöhen oder auf -1 setzen, um anzugeben, dass kein vom Nutzer festgelegtes Limit vorhanden ist.

Der Ressourcenname (ARN) gibt genau an, welche Tabelle oder welcher Index gedrosselt wird:

  • Für Tabellen: arn:aws:dynamodb:[region]:[account-id]:table/[table-name]

  • Für Indizes: arn:aws:dynamodb:[region]:[account-id]:table/[table-name]/index/[index-name]

Beispiele für vollständige Drosselungsgründe:

  • TableReadProvisionedThroughputExceeded

  • IndexWriteAccountLimitExceeded

Damit können Sie genau ermitteln, welche Ressource gedrosselt wurde, durch welche Art von Vorgang die Drosselung verursacht wurde und warum die Drosselung erfolgt ist.

Beispielausnahmen

Beispiel 1: Überschreitung der bereitgestellten Kapazität eines GSI

{
    "ThrottlingReasons": [
        {
            "reason": "IndexWriteProvisionedThroughputExceeded",
            "resource": "arn:aws:dynamodb:us-west-2:123456789012:table/CustomerOrders/index/OrderDateIndex"
        }
    ],
    "awsErrorDetails": {
        "errorCode": "ProvisionedThroughputExceeded",
        "errorMessage": "The level of configured provisioned throughput for the index was exceeded",
        "serviceName": "DynamoDB",
        "sdkHttpResponse": {
            "statusText": "Bad Request",
            "statusCode": 400
        }
    }
}

In diesem Beispiel erhält die Anwendung eine ProvisionedThroughputExceededException mit dem Grund IndexWriteProvisionedThroughputExceeded. Schreibvorgänge in den OrderDateIndex werden gedrosselt, weil der Schreibverbrauch die konfigurierte bereitgestellte Schreibkapazität des GSI überschritten hat.

Beispiel 2: On-demand Der maximale Durchsatz wurde überschritten

{
    "ThrottlingReasons": [
        {
            "reason": "TableReadMaxOnDemandThroughputExceeded",
            "resource": "arn:aws:dynamodb:us-east-1:123456789012:table/UserSessions"
        }
    ],
    "awsErrorDetails": {
        "errorMessage": "Throughput exceeds the maximum OnDemandThroughput configured on table or index",
        "errorCode": "ThrottlingException",
        "serviceName": "DynamoDB",
        "sdkHttpResponse": {
            "statusText": "Bad Request",
            "statusCode": 400
        }
    }
}

In diesem Beispiel werden Lesevorgänge aus der UserSessions-Tabelle gedrosselt, weil sie den für die Tabelle konfigurierten maximalen On-Demand-Durchsatz überschreiten.

Diagnose-Framework für DynamoDB-Drosselungen

Wenn in Ihrer Anwendung eine Drosselung auftritt, gehen Sie wie folgt vor, um das Problem zu diagnostizieren und zu beheben.

Schritt 1 – Analysieren der ThrottlingReason-Details

  1. Überprüfen Sie das Feld „reason“, um den spezifischen Grund für die Drosselung zu ermitteln. Zu den Angaben gehören die Art der gedrosselten Ressource (Tabelle oder Index), die Art des Vorgangs, der das Drosselungsereignis verursacht hat (Lesen oder Schreiben), und die Art des Limits, das überschritten wurde (Partition, bereitgestellter Durchsatz, Kontolimit).

  2. Überprüfen Sie das Feld resourceArn, um herauszufinden, welche Ressource (Tabelle oder GSI) gedrosselt wird.

  3. Mithilfe dieser kombinierten Informationen können Sie den vollständigen Kontext des Drosselungsproblems bestimmen.

    Nehmen Sie zum Beispiel dieses Szenario, in dem Sie die folgende Ausnahme ProvisionedThroughputExceededException mit dem Drosselungsgrund TableWriteKeyRangeThroughputExceeded erhalten. Der betroffene resourceARN ist arn:aws:dynamodb:us-west-2:123456789012:table/CustomerOrders.

    Diese Kombination informiert Sie darüber, dass Schreibvorgänge in Ihre CustomerOrders-Tabelle gedrosselt werden. Die Drosselung erfolgt auf Partitionsebene (nicht auf Tabellenebene, was als TableWriteProvisionedThroughputExceeded angezeigt werden würde). Die Ursache des Problems besteht darin, dass die maximale Durchsatzkapazität für einen bestimmten Schlüsselwert oder -bereich einer Partition überschritten wurde. Dies deutet auf ein Problem mit einer Hot-Partition hin.

    Wenn Sie diesen Zusammenhang zwischen den Ausnahmeelementen verstehen, können Sie geeignete Abhilfemaßnahmen ergreifen. In diesem Fall muss das Problem mit der Hot-Partition behoben werden, anstatt die bereitgestellte Gesamtkapazität der Tabelle zu erhöhen.

Schritt 2 — Identifizieren und analysieren Sie die zugehörigen Metriken CloudWatch

  1. Identifizieren Sie Ihre Metriken: Jeder Drosselungsgrund in DynamoDB entspricht direkt bestimmten CloudWatch Metriken, die Sie überwachen können, um Drosselungsereignisse zu verfolgen und zu analysieren. Sie können die entsprechenden CloudWatch Metriknamen systematisch aus dem Drosselungsgrund ableiten.

  2. Ordnen Sie Ihren Grund für die Drosselung mithilfe dieser Referenztabelle den entsprechenden CloudWatch Metriken zu:

    Vollständige Referenz zu den Gründen und Kennzahlen für die Drosselung CloudWatch
    Kategorie Drosselungsgrund Primäre Kennzahlen CloudWatch
    Überschreitung der bereitgestellten Kapazität TableReadProvisionedThroughputExceeded ReadProvisionedThroughputThrottleEvents
    TableWriteProvisionedThroughputExceeded WriteProvisionedThroughputThrottleEvents
    IndexReadProvisionedThroughputExceeded ReadProvisionedThroughputThrottleEvents (GSI)
    IndexWriteProvisionedThroughputExceeded WriteProvisionedThroughputThrottleEvents (GSI)
    Überschreitung der Partitionslimits TableReadKeyRangeThroughputExceeded ReadKeyRangeThroughputThrottleEvents
    TableWriteKeyRangeThroughputExceeded WriteKeyRangeThroughputThrottleEvents
    IndexReadKeyRangeThroughputExceeded ReadKeyRangeThroughputThrottleEvents (GSI)
    IndexWriteKeyRangeThroughputExceeded WriteKeyRangeThroughputThrottleEvents (GSI)
    On-demand Maximum überschritten TableReadMaxOnDemandThroughputExceeded ReadMaxOnDemandThroughputThrottleEvents
    TableWriteMaxOnDemandThroughputExceeded WriteMaxOnDemandThroughputThrottleEvents
    IndexReadMaxOnDemandThroughputExceeded ReadMaxOnDemandThroughputThrottleEvents (GSI)
    IndexWriteMaxOnDemandThroughputExceeded WriteMaxOnDemandThroughputThrottleEvents (GSI)
    Überschreitung der Kontolimits TableReadAccountLimitExceeded ReadAccountLimitThrottleEvents
    TableWriteAccountLimitExceeded WriteAccountLimitThrottleEvents
    IndexReadAccountLimitExceeded ReadAccountLimitThrottleEvents (GSI)
    IndexWriteAccountLimitExceeded WriteAccountLimitThrottleEvents (GSIs)

    Wenn Sie beispielsweise mindestens die Metrik erhalten habenIndexWriteProvisionedThroughputExceeded, sollten Sie die WriteProvisionedThroughputThrottleEvents CloudWatch Metrik für den spezifischen Index überwachen, der in der ResourceArn angegeben ist.

  3. Überwachen Sie diese Metriken CloudWatch , um die Häufigkeit und den Zeitpunkt der Drosselungsereignisse zu verstehen, zwischen Lese- und Schreibeinschränkungen zu unterscheiden, Zeitmuster zu erkennen, in denen die Drosselung zunimmt, und Ihre Trends bei der Kapazitätsauslastung zu verfolgen.

    DynamoDB veröffentlicht detaillierte Metriken für jede Tabelle und jeden globalen sekundären Index. Die Metriken (ReadThrottleEvents, WriteThrottleEvents undThrottledRequests) fassen alle Drosselungsereignisse in Ihrer Tabelle und ihren Indizes zusammen.

Schritt 3 — Identifizieren Sie mithilfe von Contributor Insights Ihre gedrosselten Schlüssel und Ihre hohen Zugriffsraten (für partitionsbedingte Drosselung) CloudWatch

Wenn Sie in Schritt 1 partitionsbedingte Probleme (z. B. KeyRangeThroughputExceeded Fehler) identifiziert haben, kann CloudWatch Contributor Insights for DynamoDB Ihnen helfen, zu diagnostizieren, welche Schlüssel Ihren Traffic antreiben und zu Drosselungsereignissen in Ihrer Tabelle oder Ihrem Index führen.

  1. Aktivieren Sie CloudWatch Contributor Insights für Ihre gedrosselte Tabelle oder Ihren Index auf der Grundlage Ihrer. ResourceARN

    Sie können den Modus Gedrosselte Schlüssel wählen, um sich ausschließlich auf die am stärksten gedrosselten Schlüssel zu konzentrieren. Dieser Modus eignet sich ideal für die kontinuierliche Überwachung, da er nur Ereignisse verarbeitet, bei denen eine Drosselung erfolgt. Alternativ hilft Ihnen der Modus für Schlüssel mit Zugriffen und Drosselungen dabei, nach Mustern in den am häufigsten aufgerufenen Schlüsseln zu suchen.

  2. Analysieren Sie die Berichte, um problematische Muster zu identifizieren. Suchen Sie nach Schlüsseln mit unverhältnismäßig hohen Zugriffs- oder Drosselungsraten und setzen Sie Drosselung und Datenverkehrsmuster miteinander in Verbindung. Sie können integrierte Dashboards erstellen, die Contributor Insights-Grafiken und DynamoDB-Metriken kombinieren. CloudWatch

  3. Wenn keine einzelnen Tasten unverhältnismäßig hohe Zugriffs- oder Drosselungsraten aufweisen, wird die Einschränkung des Tastenbereichs möglicherweise durch den unbegrenzten sequentiellen Zugriff auf eine Reihe von Tasten und nicht durch eine einzelne Tastenkombination verursacht. Wenn Sie fortlaufende Scan Operationen ausführen, begrenzen Sie den Leseverkehr so, dass er für einen Schlüsselbereich unter dem Maximum von 3.000 Leseeinheiten pro Sekunde pro Partition bleibt. Um insgesamt einen höheren Lesedurchsatz zu erzielen, verwenden Sie parallele (segmentierte) Scans, um den Leseverkehr gleichmäßiger auf die Partitionen zu verteilen. In ähnlicher Weise Scan konzentriert sich das Schreiben von Elementen in derselben Schlüsselreihenfolge, in der sie von a zurückgegeben werden, die Schreibvorgänge jeweils auf einen Schlüsselbereich. Dies kann zu einer Drosselung des Schlüsselbereichs führen, wenn die Schreibrate für diesen Bereich 1.000 Schreibeinheiten pro Sekunde überschreitet. Rate-limit schreibt in einen einzelnen Schlüsselbereich, um unter diesem Limit zu bleiben.

Ausführliche Informationen zur Aktivierung und Verwendung von CloudWatch Contributor Insights finden Sie unter CloudWatch Contributor Insights for DynamoDB verwenden.

Schritt 4 – Ermitteln der passenden Lösung

Nachdem Sie die konkrete Ursache der Drosselung bestimmt haben, implementieren Sie die empfohlene Lösung für Ihren spezifischen Kontext. Die geeignete Lösung hängt von mehreren Faktoren ab. Dazu gehören das Drosselungsszenario, der Kapazitätsmodus der Tabelle, Entscheidungen zum Tabellen- und Schlüsseldesign, Zugriffsmuster und Abfrageeffizienz, die Konfiguration des globalen sekundären Indexes sowie die allgemeine Systemarchitektur und die Integrationspunkte.

Detaillierte Lösungen für Ihre spezifischen Drosselungsszenarien finden Sie im Abschnitt Lösungsleitfaden für Drosselungen in DynamoDB. Diese Ressource bietet gezielte Abhilfemaßnahmen, die auf Ihren speziellen Drosselungsgrund und die Konfiguration des Kapazitätsmodus zugeschnitten sind.

Schritt 5 – Überwachen des Fortschritts

  1. Verfolgen Sie Ihre CloudWatch Metriken, die Ihrem Drosselungsszenario entsprechen.

  2. Prüfen Sie, ob Ihre Abhilfemaßnahmen wirksam sind und ein Rückgang der Drosselungsereignisse zu beobachten ist.