Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
2- Débit provisionné dépassé
La limitation de capacité allouée se produit lorsque le taux de consommation de votre application dépasse les unités de capacité de lecture ou d'écriture (RCUs/WCUs) configurées pour vos tables ou vos index secondaires globaux. DynamoDB fournit une capacité de pointe pour gérer les pics de trafic occasionnels, mais les demandes prolongées dépassant les limites que vous avez configurées entraînent une limitation. Dans ce cas, DynamoDB renvoie ProvisionedThroughputExceeded un type de raison de limitation dans l'exception de limitation. La raison indique si le problème concerne les opérations de lecture ou d'écriture et s'il affecte la table de base ou un index secondaire global.
Le throttling peut se produire, qu'Auto Scaling soit activé ou non. Auto Scaling s'adapte à l'augmentation de la consommation, mais il ne réagit pas instantanément et est limité par les limites de capacité maximale que vous configurez. Cela signifie que la régulation peut toujours se produire lors de pics de trafic soudains ou lorsque la consommation dépasse vos limites maximales d'Auto Scaling.
Le débit provisionné a dépassé les mesures d'atténuation
Cette section fournit des conseils de résolution pour les scénarios de limitation de capacité provisionnée. Avant d'utiliser ce guide, assurez-vous d'avoir identifié la raison spécifique de la limitation dans la gestion des exceptions de votre application et d'avoir déterminé le nom de ressource Amazon (ARN) de la ressource affectée. Pour plus d'informations sur la recherche des raisons de la limitation et l'identification des ressources limitées, voir. Cadre de diagnostic de la limitation DynamoDB
Avant de vous plonger dans des scénarios d'étranglement spécifiques, déterminez d'abord si le problème d'étranglement est réellement un problème à résoudre :
-
Des ralentissements occasionnels sont normaux et attendus dans les applications DynamoDB bien optimisées. La limitation signifie simplement que vous consommez 100 % de ce que vous avez provisionné. Si votre application gère correctement la régulation lors des nouvelles tentatives et que vos performances globales répondent aux exigences, il est possible que la régulation ne nécessite pas d'action immédiate.
-
Toutefois, si la régulation entraîne une latence inacceptable côté client, détériore l'expérience utilisateur ou empêche les opérations critiques de se terminer en temps voulu, appliquez les options d'atténuation ci-dessous.
Lorsque vous devez résoudre des problèmes de régulation, déterminez d'abord si votre régulation est causée par :
-
Pics de trafic temporaires : augmentations de trafic de courte durée qui dépassent votre capacité allouée mais ne sont pas durables. Celles-ci nécessitent des stratégies différentes de celles d'un trafic élevé continu.
-
Trafic élevé et continu : charges de travail soutenues qui dépassent constamment votre capacité allouée.
Pour les pics de trafic, considérez les stratégies décrites dans le blog Gérer les pics de trafic avec la capacité provisionnée d'Amazon DynamoDB publié dans. Ressources supplémentaires
Pour un trafic continu élevé, considérez les options de réglage de capacité ci-dessous :
TableReadProvisionedThroughputExceeded
Quand cela se produit
Le taux de consommation de lecture de votre application dépasse les unités de capacité de lecture allouées (RCUs) configurées pour votre table. Vous pouvez surveiller les CloudWatch métriques Diagnostic et surveillance communs pour analyser votre événement de régulation.
Approche de résolution
Envisagez les stratégies suivantes pour résoudre le problème de la limitation de la capacité de lecture :
-
Passez en mode capacité à la demande : envisagez de passer votre table en mode à la demande si vous êtes fréquemment confronté à des ralentissements dus à des pics de trafic. On-Demand élimine les problèmes de provisionnement et s'adapte automatiquement à votre charge de travail.
-
Si vous restez en mode provisionné et que Auto Scaling n'est pas activé :
-
Activez Auto Scaling pour la capacité de lecture sur votre table.
-
Si Auto Scaling est activé (par défaut pour les tables créées dans la console) :
TableWriteProvisionedThroughputExceeded
Quand cela se produit
Le taux de consommation d'écriture de votre application dépasse les unités de capacité d'écriture allouées (WCUs) configurées pour votre table. Vous pouvez surveiller les CloudWatch métriques Diagnostic et surveillance communs pour analyser votre événement de régulation.
Approche de résolution
Envisagez les stratégies suivantes pour résoudre le problème de la limitation de la capacité d'écriture :
-
Passez en mode capacité à la demande : envisagez de passer votre table en mode à la demande si vous êtes fréquemment confronté à des ralentissements dus à des pics de trafic. On-Demand élimine les problèmes de provisionnement et s'adapte automatiquement à votre charge de travail.
-
Si vous restez en mode provisionné et que Auto Scaling n'est pas activé :
-
Activez Auto Scaling pour la capacité d'écriture sur votre table.
-
Si Auto Scaling est activé (par défaut pour les tables créées dans la console) :
IndexReadProvisionedThroughputExceeded
Quand cela se produit
La consommation de lecture sur un index secondaire global (GSI) dépasse les unités de capacité de lecture allouées au GSI (). RCUs Vous pouvez surveiller les CloudWatch métriques Diagnostic et surveillance communs pour analyser votre événement de régulation.
Approche de résolution
Envisagez les stratégies suivantes pour résoudre le problème de la limitation de la capacité de lecture du GSI :
-
Passez en mode capacité à la demande : envisagez de passer la table de base à la demande si vous êtes fréquemment confronté à des ralentissements dus à des pics de trafic. On-Demand élimine les problèmes de provisionnement et s'adapte automatiquement à votre charge de travail.
-
Si vous restez en mode provisionné et que Auto Scaling n'est pas activé :
-
Envisagez d'augmenter la capacité de lecture du GSI.
-
Activez Auto Scaling pour bénéficier de la capacité de lecture sur votre GSI.
-
-
Si Auto Scaling est activé (par défaut pour les tables créées dans la console) :
IndexWriteProvisionedThroughputExceeded
Quand cela se produit
Les mises à jour des éléments de la table de base déclenchent des écritures dans un GSI qui dépassent la capacité d'écriture allouée au GSI. Cela entraîne un ralentissement de la contre-pression sur les écritures sur la table de base. Vous pouvez surveiller les CloudWatch métriques Diagnostic et surveillance communs pour analyser votre événement de régulation.
Approche de résolution
Envisagez les stratégies suivantes pour résoudre le problème de la limitation de la capacité d'écriture GSI :
-
Passez en mode capacité à la demande : envisagez de passer la table de base à la demande si vous êtes fréquemment confronté à des ralentissements dus à des pics de trafic. On-Demand élimine les problèmes de provisionnement et s'adapte automatiquement à votre charge de travail.
-
Si vous restez en mode provisionné et que Auto Scaling n'est pas activé :
-
Envisagez d'augmenter la capacité d'écriture du GSI.
-
Activez Auto Scaling pour bénéficier de la capacité d'écriture sur votre GSI.
-
-
Si Auto Scaling est activé (par défaut pour les tables créées dans la console) :
Diagnostic et surveillance communs
Lors de la résolution des erreurs de débit, plusieurs CloudWatch mesures peuvent aider à en identifier la cause première.
CloudWatch Indicateurs essentiels
Surveillez ces indicateurs clés pour diagnostiquer la limitation de la capacité allouée :
-
Événements de limitation :
ReadProvisionedThroughputThrottleEventsetWriteProvisionedThroughputThrottleEventssuivez à quel moment les demandes sont limitées pour cette raison.ReadThrottleEventsetWriteThrottleEventssuivez les demandes de lecture ou d'écriture qui dépassent la capacité allouée. -
Consommation de capacité :
ConsumedReadCapacityUnitsetConsumedWriteCapacityUnitsaffiche l'utilisation réelle. -
Capacité allouée :
ProvisionedReadCapacityUnitsetProvisionedWriteCapacityUnitsaffiche les limites configurées.
Procédures de résolution
Augmenter la capacité de débit des tables
Utilisez cette procédure lorsque Auto Scaling n'est pas activé et que vous avez besoin d'une augmentation de capacité immédiate.
-
Mettez à jour la capacité provisionnée de votre table à l'aide de la console AWS CLI DynamoDB ou du SDK :
-
Pour la capacité de lecture : augmentez le
ReadCapacityUnitsparamètre, qui indique le nombre maximum de lectures hautement cohérentes consommées par seconde avant que DynamoDB ne limite les demandes. -
Pour la capacité d'écriture : augmentez le
WriteCapacityUnitsparamètre, qui indique le nombre maximum d'écritures consommées par seconde avant que DynamoDB ne limite les demandes.
-
-
Vérifiez que vos nouveaux paramètres de capacité ne dépassent pas les quotas de débit par table et que la consommation totale de votre compte reste inférieure aux quotas de débit par compte de votre région. Si vous approchez de ces limites, envisagez plutôt de passer en mode capacité à la demande.
Configuration de la table Auto Scaling pour ajuster la capacité de lecture ou d'écriture de votre table ou de votre GSI
Configurez DynamoDB Auto Scaling pour ajuster automatiquement la capacité de lecture ou d'écriture en fonction des modèles de trafic. Vous pouvez configurer Auto Scaling indépendamment pour les deux tables GSIs, avec des contrôles distincts pour les unités de capacité de lecture et d'écriture.
-
Activez Auto Scaling pour la capacité de lecture, la capacité d'écriture ou les deux sur votre table ou GSI.
-
Définissez un pourcentage d'utilisation cible avec une marge de manœuvre pour les pics de trafic.
Note
La baisse du taux d'utilisation des cibles augmente les coûts et augmente la fréquence d'adaptation. Les objectifs inférieurs à 40 % peuvent entraîner un surprovisionnement. Surveillez les modèles d'utilisation et les coûts pour trouver un équilibre entre performance et efficacité.
-
Définissez les limites de capacité :
-
Minimum RCUs/WCUs: Maintient une capacité suffisante pendant les périodes de faible trafic.
-
Maximum RCUs/WCUs: répond aux pics de trafic et protège contre les événements de montée en flèche.
-
Pour obtenir des conseils sur la configuration et la gestion de DynamoDB Auto Scaling, reportez-vous à la section Gestion automatique de la capacité de débit avec DynamoDB Auto Scaling.
Note
Auto Scaling prend généralement plusieurs minutes pour répondre aux modifications du trafic. En cas de pics de trafic soudains, la capacité de rafale de votre table fournit une protection immédiate pendant que Auto Scaling s'ajuste. Configurez l'utilisation cible avec une marge de manœuvre adéquate afin de laisser le temps de dimensionner les opérations et de préserver la capacité de pointe en cas de demande imprévue.
Optimisation des paramètres de lecture ou d'écriture de votre table ou de votre index Auto Scaling
Utilisez cette procédure lorsque Auto Scaling est activé mais que la régulation persiste. Vous pouvez régler Auto Scaling indépendamment pour les tables et les index secondaires globaux (GSIs), avec des contrôles distincts pour les unités de capacité de lecture et d'écriture.
-
Ajustez l'utilisation cible : envisagez de réduire l'utilisation cible de votre table ou GSIs de déclencher le dimensionnement plus tôt avant que la limitation ne se produise. Assurez-vous de surveiller votre trafic après avoir effectué ces ajustements. Consultez Configuration de la table Auto Scaling pour ajuster la capacité de lecture ou d'écriture de votre table ou de votre GSI pour plus d'informations sur la consommation de capacité et les implications financières.
-
Vérifiez les limites de capacité : assurez-vous que vos paramètres de capacité minimale et maximale correspondent à vos modèles de charge de travail réels.
Passage en mode capacité à la demande
Pour des informations générales sur le changement de mode de capacité, consultezConsidérations relatives au changement de mode de capacité dans DynamoDB. Reportez-vous aux Service Quotas pour en savoir plus sur les contraintes spécifiques liées au changement de mode.
Augmenter la capacité de débit du GSI
Utilisez cette procédure lorsque Auto Scaling n'est pas activé sur votre GSI ou si vous avez besoin d'une augmentation de capacité immédiate.
-
Mettez à jour la capacité provisionnée du GSI à l'aide de la console DynamoDB ou du SDK : AWS CLI
-
Pour la capacité de lecture : augmentez le
ReadCapacityUnitsparamètre du GSI spécifique, qui indique le nombre maximal de lectures que le GSI peut effectuer par seconde avant que DynamoDB ne limite les demandes. Notez que GSIs seules les lectures éventuellement cohérentes sont prises en charge. -
Pour la capacité d'écriture : augmentez le
WriteCapacityUnitsparamètre pour le GSI spécifique, qui indique le nombre maximum d'écritures que le GSI peut consommer par seconde avant que DynamoDB ne limite les demandes.
-
-
Assurez-vous que la capacité de débit allouée au GSI reste dans les limites des quotas de débit par compte et par table.
Ressources supplémentaires
-
Pour obtenir des informations détaillées sur la gestion des pics de trafic dans les tableaux de capacité provisionnée de DynamoDB, y compris les différentes stratégies allant de l'utilisation d'Auto Scaling et de la capacité en rafale à la gestion stratégique de l'accélérateur, consultez Gérer les pics de trafic
avec la capacité provisionnée d'Amazon DynamoDB. -
Pour plus d'informations sur l'utilisation d'une expression cron pour planifier une politique de dimensionnement, voir Optimiser les coûts en planifiant la capacité allouée pour DynamoDB
. -
Pour obtenir des informations pratiques sur la surveillance et l'analyse des modèles d'utilisation du débit pour vos tables DynamoDB en mode capacité allouée, consultez Comment évaluer l'utilisation du débit pour les tables Amazon DynamoDB
en mode provisionné.