Performance

Vérifie si le cluster de base de données Amazon Aurora dispose des ressources nécessaires pour prendre en charge une charge de travail de lecture.

c1qf5bt038

Jaune :

Augmentation du nombre de lectures de base de données : la charge de base de données était élevée et la base de données lisait plus de lignes qu'elle n'écrivait ou ne mettait à jour les lignes.

Nous vous recommandons de régler vos requêtes pour réduire la charge de la base de données ou d'ajouter une instance de base de données de lecture à votre cluster de bases de données avec la même classe et la même taille que l'instance de base de données d'écriture du cluster. La configuration actuelle comporte au moins une instance de base de données dont la charge de base de données est constamment élevée, principalement en raison d'opérations de lecture. Répartissez ces opérations en ajoutant une autre instance de base de données au cluster et en dirigeant la charge de travail de lecture vers le point de terminaison en lecture seule du cluster de base de données.

Un cluster de base de données Aurora possède un point de terminaison de lecteur pour les connexions en lecture seule. Ce point de terminaison utilise l'équilibrage de charge pour gérer les requêtes qui contribuent le plus à la charge de la base de données dans votre cluster de bases de données. Le point de terminaison du lecteur dirige ces instructions vers les répliques Aurora Read et réduit la charge sur l'instance principale. Le point de terminaison du lecteur adapte également la capacité à gérer les SELECT requêtes simultanées en fonction du nombre de répliques Aurora Read dans le cluster.

Pour plus d'informations, consultez les sections Ajout de répliques Aurora à un cluster de base de données et Gestion des performances et du dimensionnement des clusters de bases de données Aurora.

Vérifie si l'autoscaling ou la capacité à la demande sont activés pour vos tables Amazon DynamoDB et vos index secondaires globaux.

L'autoscaling d'Amazon DynamoDB utilise le service d'autoscaling d'application pour ajuster de manière dynamique la capacité de débit provisionnée en votre nom en réponse aux schémas de trafic réels. Cela permet à une table ou à un index secondaire global d'augmenter sa capacité de lecture et d'écriture approvisionnée afin de gérer les hausses soudaines de trafic sans limitation. Lorsque la charge de travail diminue, la scalabilité automatique d'application réduit le débit de sorte que vous ne payez pas pour une capacité approvisionnée non utilisée.

Vous pouvez ajuster la configuration du contrôle à l'aide des paramètres de vos AWS Config règles.

Pour plus d'informations, voir Gestion automatique de la capacité de débit avec l'autoscaling de DynamoDB.

c18d2gz136

AWS Config Règle gérée : dynamodb-autoscaling-enabled

Jaune : l'autoscaling n'est pas activé pour vos tables DynamoDB et/ou vos index secondaires globaux.

Activez l'autoscaling pour vos tables Amazon DynamoDB, à moins que vous ne disposiez déjà d'un mécanisme permettant de mettre à l'échelle automatiquement le débit provisionné de votre table DynamoDB et/ou de vos index secondaires globaux en fonction de vos exigences en matière de charge de travail.

Pour plus d'informations, consultez la section Utilisation de la console AWS de gestion avec DynamoDB auto scalingp.

Gestion automatique de la capacité de débit avec l'autoscaling de DynamoDB

Vérifie si EBS l'optimisation Amazon est activée pour vos EC2 instances Amazon.

Une instance EBS optimisée pour Amazon utilise une pile de configuration optimisée et fournit une capacité dédiée supplémentaire pour Amazon EBS I/O. Cette optimisation fournit les meilleures performances pour vos EBS volumes Amazon en minimisant les conflits entre Amazon EBS I/O et le reste du trafic provenant de votre instance.

Pour plus d'informations, consultez Amazon EBS —optimized instances.

c18d2gz142

AWS Config Règle gérée : ebs-optimized-instance

Jaune : EBS l'optimisation Amazon n'est pas activée sur les EC2 instances Amazon prises en charge.

Activez l'EBSoptimisation Amazon sur les instances prises en charge.

Pour plus d'informations, voir Activer EBS l'optimisation au lancement.

Amazon EBS : instances optimisées

Vérifie les volumes provisionnés IOPS (SSD) attachés à une instance Amazon Elastic Compute Cloud (EBSAmazonEC2) optimisable par Amazon qui n'est pas EBS optimisée.

Les volumes provisionnés IOPS (SSD) dans l'Amazon Elastic Block Store (AmazonEBS) sont conçus pour fournir les performances attendues uniquement lorsqu'ils sont attachés à une instance EBS optimisée.

PPkZrjsH2q

Jaune : une EC2 instance Amazon qui peut être EBS optimisée possède un volume Provisioned IOPS (SSD) attaché mais elle n'est pas EBS optimisée.

Créez une nouvelle instance EBS optimisée, détachez le volume, puis attachez-le à nouveau à votre nouvelle instance. Pour plus d'informations, consultez Amazon EBS -Optimized Instances et Attacher un EBS volume Amazon à une instance.

Vérifie les volumes Amazon Elastic Block Store (AmazonEBS) qui étaient en cours d'exécution à tout moment pendant la période de référence. Cette vérification vous avertit si des EBS volumes ont été sous-approvisionnés pour vos charges de travail. Une utilisation élevée constante peut indiquer des performances optimisées et stables, mais peut également indiquer qu'une application ne dispose pas de ressources suffisantes.

COr6dfpM04

Jaune : EBS volume sous-approvisionné pendant la période de rétrospective. Pour déterminer si un volume est sous-provisionné, nous prenons en compte toutes les CloudWatch mesures par défaut (y compris IOPS le débit). L'algorithme utilisé pour identifier les EBS volumes sous-approvisionnés suit les AWS meilleures pratiques. L'algorithme est mis à jour lorsqu'un nouveau modèle a été identifié.

Pensez à augmenter les volumes d'utilisation élevée.

Pour de plus amples informations, veuillez consulter Optez AWS Compute Optimizer pour les Trusted Advisor chèques.

Vérifie si un groupe Amazon EC2 Auto Scaling est créé à partir d'un modèle de EC2 lancement Amazon.

Utilisez un modèle de lancement pour créer vos groupes Amazon EC2 Auto Scaling afin de garantir l'accès aux dernières fonctionnalités et améliorations des groupes Auto Scaling. notamment la gestion des versions et les types d'instances multiples.

Pour plus d'informations, voir Modèles de lancement.

c18d2gz102

AWS Config Règle gérée : autoscaling-launch-template

Jaune : le groupe Amazon EC2 Auto Scaling n'est pas associé à un modèle de lancement valide.

Utilisez un modèle de EC2 lancement Amazon pour créer vos groupes Amazon EC2 Auto Scaling.

Pour plus d'informations, voir Création d'un modèle de lancement pour un groupe Auto Scaling.

Vérifie les EBS volumes Amazon dont les performances peuvent être affectées par la capacité de débit maximale de l'EC2instance Amazon à laquelle ils sont attachés.

Pour optimiser les performances, vous devez vous assurer que le débit maximal d'une EC2 instance Amazon est supérieur au débit maximal agrégé des volumes attachésEBS. Cette vérification calcule le débit de EBS volume total pour chaque période de cinq minutes du jour précédent (sur la base du temps universel coordonné (UTC)) pour chaque instance EBS optimisée et vous alerte si l'utilisation pendant plus de la moitié de ces périodes était supérieure à 95 % du débit maximal de l'instance pendant plus de la moitié de ces périodes. EC2

Bh2xRR2FGH

Jaune : le jour précédent (UTC), le débit agrégé (mégaoctets/s) des EBS volumes attachés à l'EC2instance dépassait 95 % du débit publié entre l'instance et les volumes plus de 50 % du temps. EBS

Comparez le débit maximal de vos EBS volumes Amazon (voir Amazon EBS Volume Types) avec le débit maximal de l'EC2instance Amazon à laquelle ils sont attachés. Consultez la section Types d'instances qui prennent en charge EBS l'optimisation.

Envisagez d'associer vos volumes à une instance qui prend en charge un débit plus élevé vers Amazon EBS pour des performances optimales.

Vérifie si le type de virtualisation d'une EC2 instance Amazon est paravirtuel.

Il est recommandé d'utiliser des instances de machines virtuelles matérielles (HVM) plutôt que des instances paravirtuelles, dans la mesure du possible. Cela est dû aux améliorations apportées à la HVM virtualisation et à la disponibilité de pilotes photovoltaïques HVMAMIs, qui ont permis de combler l'écart de performance qui existait historiquement entre le photovoltaïque et HVM les clients. Il est important de noter que les types d'instances de la génération actuelle ne prennent pas en charge le photovoltaïqueAMIs. Par conséquent, le choix d'un type d'HVMinstance garantit les meilleures performances et la meilleure compatibilité avec le matériel moderne.

Pour plus d'informations, consultez la section Types AMI de virtualisation Linux.

c18d2gz148

AWS Config Règle gérée : ec2- paravirtual-instance-check

Jaune : le type de virtualisation des EC2 instances Amazon est paravirtuel.

Utilisez HVM la virtualisation pour vos EC2 instances Amazon et utilisez un type d'instance compatible.

Pour plus d'informations sur le choix du type de virtualisation approprié, voir Compatibilité pour modifier le type d'instance.

Compatibilité pour modifier le type d'instance

Vérifie si les définitions de ECS tâches Amazon ont une limite de mémoire définie pour ses définitions de conteneurs. La quantité totale de mémoire réservée pour tous les conteneurs d'une tâche doit être inférieure à la valeur Mémoire de la tâche.

Pour plus d'informations, voir Définitions de conteneur.

c18d2gz176

AWS Config Règle gérée : ecs-task-definition-memory -hard-limit

Jaune : la limite maximale de ECS mémoire Amazon n'est pas définie.

Allouez de la mémoire à vos ECS tâches Amazon afin d'éviter de manquer de mémoire. Si votre conteneur tente de dépasser la mémoire spécifiée, il est terminé.

Pour plus d'informations, consultez Comment allouer de la mémoire aux tâches sur Amazon ECS ? .

Réservation de cluster

Vérifie si le système de EFS fichiers Amazon du client est actuellement configuré pour utiliser le mode Bursting Throughput.

Les systèmes EFS de fichiers en mode Bursting Throughput [1] fournissent un niveau de débit de référence constant (50 kB/s par GiB de données EFS dans le stockage standard) et utilisent un modèle de crédit pour fournir des niveaux supérieurs de performance de « débit en rafale » lorsque des « crédits en rafale » sont disponibles. Lorsque vous épuisez vos crédits, les performances de votre système de fichiers sont limitées à ce niveau de référence inférieur, ce qui peut entraîner des ralentissements, des délais d'attente ou d'autres formes d'impact sur les performances pour vos utilisateurs finaux ou vos applications.

c1dfprch02

Nous vous recommandons de mettre à jour la configuration de votre système de fichiers en mode de débit élastique [2] pour permettre à vos utilisateurs et à vos applications d'atteindre le débit souhaité. En mode Elastic Throughput, votre système de fichiers peut atteindre jusqu'à 10 Go/s de débit de lecture ou 3 Go/s de débit d'écriture, selon la AWS région [3], et vous ne payez que pour le débit que vous utilisez. Notez que vous pouvez mettre à jour la configuration de votre système de fichiers pour basculer à la demande entre les modes de débit élastique et en rafales, et que les systèmes de fichiers en mode de débit élastique peuvent occasionner des frais supplémentaires pour le transfert de données [4].

Le paramètre autovacuum est désactivé pour vos instances de base de données. La désactivation de l'aspirateur automatique augmente le gonflement de la table et de l'index et a un impact sur les performances.

Nous vous recommandons d'activer l'autovacuum dans vos groupes de paramètres de base de données.

c1qf5bt025

Jaune : l'autovacuum est désactivé pour les groupes de paramètres de base de données.

Activez le paramètre autovacuum dans vos groupes de paramètres de base de données.

La SQL base de données Postgre nécessite une maintenance périodique connue sous le nom d'aspirateur. Autovacuum dans Postgre SQL automatise le fonctionnement VACCUUMet les commandes. ANALYZE Ce processus rassemble les statistiques du tableau et supprime les lignes mortes. Lorsque l'autovacuum est désactivé, l'augmentation de la table, le gonflement de l'index et les statistiques périmées ont un impact sur les performances de la base de données.

Pour plus d'informations, consultez Comprendre l'autovacuum dans Amazon RDS pour les environnements Postgre SQL.

Vos clusters de base de données prennent en charge des volumes allant jusqu'à 64 TiB. Les dernières versions du moteur prennent en charge des volumes allant jusqu'à 128 TiB. Nous vous recommandons de mettre à niveau la version du moteur de votre cluster de base de données vers les dernières versions afin de prendre en charge des volumes allant jusqu'à 128 TiB.

c1qf5bt017

Jaune : les clusters de base de données ne prennent en charge que les volumes jusqu'à 64 TiB.

Mettez à niveau la version du moteur de vos clusters de base de données pour prendre en charge des volumes allant jusqu'à 128 TiB.

Lorsque vous augmentez votre application sur un seul cluster de base de données Amazon Aurora, vous risquez de ne pas atteindre la limite si la limite de stockage est de 128 TiB. L'augmentation de la limite de stockage permet d'éviter de supprimer les données ou de diviser la base de données sur plusieurs instances.

Pour plus d'informations, consultez les limites de taille d'Amazon Aurora.

Nous vous recommandons d'utiliser la même classe et la même taille d'instance de base de données pour toutes les instances de base de données de votre cluster de base de données.

c1qf5bt009

Rouge : les clusters de base de données contiennent des instances de base de données avec des classes d'instances hétérogènes.

Utilisez la même classe et la même taille d'instance pour toutes les instances de base de données de votre cluster de base de données.

Lorsque les instances de base de données de votre cluster de base de données utilisent différentes classes ou tailles d'instances de base de données, il peut y avoir un déséquilibre dans la charge de travail des instances de base de données. Lors d'un basculement, l'une des instances de base de données du lecteur devient une instance de base de données du rédacteur. Si les instances de base de données utilisent la même classe et la même taille d'instance de base de données, la charge de travail peut être équilibrée pour les instances de base de données de votre cluster de base de données.

Pour plus d'informations, consultez la section Répliques d'Aurora.

Nous vous recommandons d'utiliser la même classe et la même taille d'instance de base de données pour toutes les instances de base de données de votre cluster de base de données.

c1qf5bt008

Rouge : les clusters de base de données contiennent des instances de base de données de tailles d'instance hétérogènes.

Utilisez la même classe et la même taille d'instance pour toutes les instances de base de données de votre cluster de base de données.

Lorsque les instances de base de données de votre cluster de base de données utilisent différentes classes ou tailles d'instances de base de données, il peut y avoir un déséquilibre dans la charge de travail des instances de base de données. Lors d'un basculement, l'une des instances de base de données du lecteur devient une instance de base de données du rédacteur. Si les instances de base de données utilisent la même classe et la même taille d'instance de base de données, la charge de travail peut être équilibrée pour les instances de base de données de votre cluster de base de données.

Pour plus d'informations, consultez la section Répliques d'Aurora.

Les paramètres de mémoire des instances de base de données sont significativement différents des valeurs par défaut. Ces paramètres peuvent avoir un impact sur les performances et provoquer des erreurs.

Nous vous recommandons de réinitialiser les paramètres de mémoire personnalisés de l'instance de base de données à leurs valeurs par défaut dans le groupe de paramètres de base de données.

c1qf5bt020

Jaune : les groupes de paramètres de base de données ont des paramètres de mémoire qui divergent considérablement par rapport aux valeurs par défaut.

Réinitialisez les paramètres de mémoire à leurs valeurs par défaut.

Pour plus d'informations, consultez Bonnes pratiques de configuration des paramètres pour Amazon RDS for MySQL, partie 1 : Paramètres liés aux performances.

Le planificateur ou l'optimiseur de requêtes ne peut pas utiliser le type de plan de scan indexé uniquement lorsqu'il est désactivé.

Nous vous recommandons de définir la valeur du paramètre enable_indexonlyscan sur 1.

c1qf5bt028

Jaune : le paramètre enable_indexonlyscan est désactivé pour les groupes de paramètres de base de données.

Définissez le paramètre enable_indexonlyscan sur 1.

Lorsque vous désactivez le paramètre enable_indexonlyscan, il empêche le planificateur de requêtes de sélectionner un plan d'exécution optimal. Le planificateur de requêtes utilise un autre type de plan, tel que le scan d'index, qui peut augmenter le coût des requêtes et le temps d'exécution. Le type de plan de numérisation à index uniquement permet de récupérer les données sans accéder aux données de la table.

Pour plus d'informations, consultez enable_indexonlyscan (boolean) sur le site Web de documentation de Postgre. SQL

Le planificateur ou l'optimiseur de requêtes ne peut pas utiliser le type de plan d'analyse d'index lorsqu'il est désactivé.

Nous vous recommandons de définir la valeur du paramètre enable_indexscan sur 1.

c1qf5bt029

Jaune : le paramètre enable_indexscan est désactivé pour les groupes de paramètres de base de données.

Définissez le paramètre enable_indexscan sur 1.

Lorsque vous désactivez le paramètre enable_indexscan, il empêche le planificateur de requêtes de sélectionner un plan d'exécution optimal. Le planificateur de requêtes utilise un autre type de plan, tel que le scan d'index, qui peut augmenter le coût des requêtes et le temps d'exécution.

Pour plus d'informations, consultez enable_indexscan (boolean) sur le site Web de documentation de Postgre. SQL

La journalisation générale est activée pour votre instance de base de données. Ce paramètre est utile pour résoudre les problèmes liés à la base de données. Cependant, l'activation de la journalisation générale augmente le nombre d'opérations d'E/S et l'espace de stockage alloué, ce qui peut entraîner des conflits et une dégradation des performances.

Vérifiez vos exigences en matière d'utilisation générale de la journalisation. Nous vous recommandons de définir la valeur du paramètre general_logging sur 0.

c1qf5bt037

Jaune : general_logging est activé pour les groupes de paramètres de base de données.

Vérifiez vos exigences en matière d'utilisation générale de la journalisation. Si ce n'est pas obligatoire, nous vous recommandons de définir la valeur du paramètre general_logging sur 0.

Le journal général des requêtes est activé lorsque la valeur du paramètre general_logging est 1. Le journal général des requêtes contient les enregistrements des opérations du serveur de base de données. Le serveur écrit des informations dans ce journal lorsque les clients se connectent ou se déconnectent et les journaux contiennent chaque SQL instruction reçue des clients. Le journal général des requêtes est utile lorsque vous suspectez une erreur chez un client et que vous souhaitez trouver les informations que le client doit envoyer au serveur de base de données.

Pour plus d'informations, consultez la section Présentation des journaux de RDS for My SQL database.

La mise en mémoire tampon des modifications permet à une instance My SQL DB de différer quelques écritures, qui sont nécessaires pour maintenir les index secondaires. Cette fonctionnalité était utile dans les environnements où les disques étaient lents. La modification de la configuration de la mise en mémoire tampon a légèrement amélioré les performances de la base de données, mais a retardé la reprise après incident et prolongé les temps d'arrêt pendant la mise à niveau.

Nous vous recommandons de définir la valeur du paramètre innodb_change_buffering sur. NONE

c1qf5bt021

Jaune : le paramètre innodb_change_buffering est défini sur une valeur optimale basse pour les groupes de paramètres de base de données.

Définissez la valeur du paramètre innodb_change_buffering sur dans vos groupes de paramètres de base de données NONE.

Pour plus d'informations, consultez Bonnes pratiques de configuration des paramètres pour Amazon RDS for MySQL, partie 1 : Paramètres liés aux performances.

Le paramètre innodb_open_files contrôle le nombre de fichiers qu'InnoDB peut ouvrir simultanément. InnoDB ouvre tous les fichiers log et tablespace système lorsque mysqld est en cours d'exécution.

Votre instance de base de données a une faible valeur pour le nombre maximal de fichiers qu'InnoDB peut ouvrir en même temps. Nous vous recommandons de définir le paramètre innodb_open_files sur une valeur minimale de 65.

c1qf5bt033

Jaune : le paramètre des fichiers ouverts d'InnoDB est mal configuré pour les groupes de paramètres de base de données.

Définissez le paramètre innodb_open_files sur une valeur minimale de 65.

Le paramètre innodb_open_files contrôle le nombre de fichiers qu'InnoDB peut ouvrir simultanément. InnoDB garde tous les fichiers journaux et les fichiers d'espace disque logique du système ouverts lorsque mysqld est en cours d'exécution. InnoDB doit également ouvrir quelques fichiers .ibd, si le modèle de file-per-table stockage est utilisé. Lorsque le paramètre innodb_open_files est faible, cela a un impact sur les performances de la base de données et le serveur peut ne pas démarrer.

Pour plus d'informations, consultez Options de démarrage et variables système d'InnoDB - innodb_open_files sur le site Web de documentation. MySql

Votre instance de base de données n'est pas configurée pour conserver les statistiques InnoDB sur le disque. Lorsque les statistiques ne sont pas stockées, elles sont recalculées à chaque redémarrage de l'instance et à chaque accès à la table. Cela entraîne des variations dans le plan d'exécution des requêtes. Vous pouvez modifier la valeur de ce paramètre global au niveau de la table.

Nous vous recommandons de définir la valeur du paramètre innodb_stats_persistent sur ON.

c1qf5bt032

Jaune : les groupes de paramètres de base de données ont des statistiques d'optimisation qui ne sont pas conservées sur le disque.

Définissez la valeur du paramètre innodb_stats_persistent sur ON.

Si le paramètre innodb_stats_persistent est défini sur ON, les statistiques de l'optimiseur sont conservées au redémarrage de l'instance. Cela améliore la stabilité du plan d'exécution et la cohérence des performances des requêtes. Vous pouvez modifier la persistance des statistiques globales au niveau de la table en utilisant la clause STATS_ PERSISTENT lorsque vous créez ou modifiez une table.

Pour plus d'informations, consultez Bonnes pratiques de configuration des paramètres pour Amazon RDS for MySQL, partie 1 : Paramètres liés aux performances.

Vérifie si l'RDSinstance Amazon ou l'instance de base de données Amazon Aurora possède la capacité système requise pour fonctionner.

c1qf5bt039

Jaune :

O ut-of-memory kills : lorsqu'un processus sur l'hôte de base de données est arrêté en raison d'une réduction de la mémoire au niveau du système d'exploitation, le compteur Out Of Memory (OOM) augmente.

Échange excessif : les valeurs des métriques os.memory.swap.in et os.memory.swap.out étaient élevées.

Nous vous recommandons de régler vos requêtes de manière à utiliser moins de mémoire ou d'utiliser un type d'instance de base de données avec une plus grande quantité de mémoire allouée. Lorsque la mémoire de l'instance est insuffisante, cela a un impact sur les performances de la base de données.

Aucun ut-of-memory kill n'a été détecté : le noyau Linux invoque le Out of Memory (OOM) Killer lorsque les processus exécutés sur l'hôte nécessitent plus que la mémoire physiquement disponible sur le système d'exploitation. Dans ce cas, le OOM Killer passe en revue tous les processus en cours d'exécution et arrête un ou plusieurs processus afin de libérer de la mémoire système et de maintenir le système en marche.

Un échange est détecté : lorsque la mémoire n'est pas suffisante sur l'hôte de base de données, le système d'exploitation envoie quelques pages utilisées au minimum sur le disque dans l'espace de swap. Ce processus de déchargement a un impact sur les performances de la base de données.

Pour plus d'informations, consultez Amazon RDS Instance Types et yourAmazon RDS instance Scaling.

Vos instances de base de données utilisent le stockage magnétique. Le stockage magnétique n'est pas recommandé pour la plupart des instances de base de données. Choisissez un autre type de stockage : usage général (SSD) ou provisionnéIOPS.

c1qf5bt000

Jaune : les RDS ressources Amazon utilisent le stockage magnétique.

Choisissez un autre type de stockage : usage général (SSD) ou provisionnéIOPS.

Le stockage magnétique est un type de stockage de génération antérieure. Le type de stockage à usage général (SSD) ou provisionné IOPS est le type de stockage recommandé pour les nouvelles exigences de stockage. Ces types de stockage offrent des performances supérieures et constantes, ainsi que des options de taille de stockage améliorées.

Pour plus d'informations, consultez la section Volumes des générations précédentes.

Les grandes pages peuvent augmenter l'évolutivité de la base de données, mais votre instance de base de données n'utilise pas de grandes pages. Nous vous recommandons de définir la valeur du paramètre use_large_pages sur ONLYdans le groupe de paramètres de base de données de votre instance de base de données.

c1qf5bt024

Jaune : les groupes de paramètres de base de données n'utilisent pas de grandes pages.

Définissez la valeur du paramètre use_large_pages sur ONLYdans vos groupes de paramètres de base de données.

Pour plus d'informations, voir HugePages Activation RDS d'une instance Oracle.

Lorsque les modifications nécessitent la purge de votre cache de requêtes, votre instance de base de données semble bloquée. La plupart des charges de travail ne bénéficient pas d'un cache de requête. Le cache de requêtes a été supprimé de My SQL version 8.0. Nous vous recommandons de définir le paramètre query_cache_type sur 0.

c1qf5bt022

Jaune : le cache de requêtes est activé pour les groupes de paramètres de base de données.

Définissez la valeur du paramètre query_cache_type sur 0 dans vos groupes de paramètres de base de données.

Pour plus d'informations, consultez Bonnes pratiques de configuration des paramètres pour Amazon RDS for MySQL, partie 1 : Paramètres liés aux performances.

Votre base de données exécute une classe d'instance de base de données de génération précédente. Nous avons remplacé les classes d'instance de base de données d'une génération précédente par des classes d'instance de base de données offrant un meilleur coût, de meilleures performances, ou les deux. Nous vous recommandons d'exécuter votre instance de base de données avec une classe d'instance de base de données de nouvelle génération.

c1qf5bt015

Rouge : les instances de base de données utilisent une classe d'instance de base de données de fin de support.

Passez à la dernière classe d'instance de base de données.

Pour plus d'informations, consultez Moteurs de base de données pris en charge pour les classes d'instances de base de données.

Les bases de données dotées de la version majeure actuelle du moteur de base de données ne seront pas prises en charge. Nous vous recommandons de passer à la dernière version majeure qui inclut de nouvelles fonctionnalités et améliorations.

c1qf5bt014

Rouge : les RDS ressources utilisent des versions majeures en fin de support.

Effectuez une mise à niveau vers la dernière version majeure du moteur de base de données.

Amazon RDS publie de nouvelles versions pour les moteurs de base de données pris en charge afin de maintenir vos bases de données avec la dernière version. Les nouvelles versions publiées peuvent inclure des corrections de bogues, des améliorations de sécurité et d'autres améliorations du moteur de base de données. Vous pouvez minimiser le temps d'arrêt requis pour la mise à niveau de l'instance de base de données en utilisant un déploiement bleu/vert.

Pour plus d’informations, consultez les ressources suivantes :

Nous vous recommandons de mettre à niveau la version majeure vers la dernière version du moteur prise en charge par Amazon RDS afin de continuer à bénéficier du support de licence actuel. La version du moteur de votre base de données ne sera pas prise en charge avec la licence actuelle.

c1qf5bt016

Rouge : Amazon RDS Resources utilise l'édition du moteur de fin de support dans le cadre d'un modèle avec licence incluse.

Nous vous recommandons de mettre à niveau votre base de données vers la dernière version prise en charge par Amazon RDS pour continuer à utiliser le modèle sous licence.

Pour plus d'informations, consultez la section Mises à niveau des versions majeures d'Oracle.

Vérifie les jeux d'enregistrements de ressource qui peuvent être modifiés en jeux d'enregistrements de ressource d'alias afin d'améliorer les performances et de faire des économies.

Un jeu d'enregistrements de ressources alias achemine les DNS requêtes vers une AWS ressource (par exemple, un équilibreur de charge Elastic Load Balancing ou un bucket Amazon S3) ou vers un autre jeu d'enregistrements de ressources Route 53. Lorsque vous utilisez des ensembles d'enregistrements de ressources alias, Route 53 achemine gratuitement vos DNS requêtes vers les AWS ressources.

Les zones hébergées créées par AWS les services n'apparaîtront pas dans les résultats de votre vérification.

B913Ef6fb4

Remplacez les jeux d'enregistrements de CNAME ressources répertoriés par des jeux d'enregistrements de ressources alias ; voir Choisir entre des ensembles d'enregistrements de ressources avec alias et sans alias.

Vous devez également modifier le type d'enregistrement de A CNAME à A ouAAAA, en fonction de la AWS ressource. Voir Valeurs à spécifier lorsque vous créez ou modifiez des enregistrements Amazon Route 53.

Acheminement des requêtes vers les AWS ressources

Vérifie les AWS Lambda fonctions qui ont été invoquées au moins une fois pendant la période de rétrospective. Cette vérification vous avertit si l'une de vos fonctions Lambda a été sous-provisionnée pour la taille de la mémoire. Lorsque des fonctions Lambda sont sous-provisionnées pour la taille de la mémoire, ces fonctions mettent plus de temps à se terminer.

COr6dfpM06

Jaune : fonction Lambda sous-provisionnée pour la taille de la mémoire pendant la période de recherche. Pour déterminer si une fonction Lambda est sous-provisionnée, nous prenons en compte toutes les CloudWatch métriques par défaut pour cette fonction. L'algorithme utilisé pour identifier les fonctions Lambda sous-provisionnées en termes de taille de mémoire suit les meilleures pratiques. AWS L'algorithme est mis à jour lorsqu'un nouveau modèle a été identifié.

Pensez à augmenter la taille de la mémoire de vos fonctions Lambda.

Pour de plus amples informations, veuillez consulter Optez AWS Compute Optimizer pour les Trusted Advisor chèques.

Vérifie si AWS Lambda les fonctions sont configurées avec une limite d'exécution simultanée au niveau des fonctions.

La simultanéité est le nombre de demandes en cours de vol traitées simultanément AWS par votre fonction Lambda. Pour chaque demande simultanée, Lambda fournit une instance distincte de votre environnement d’exécution.

Vous pouvez spécifier la limite de simultanéité réservée minimale et maximale à l'aide des ConcurrencyLimitHighparamètres concurrencyLimitLowet de vos AWS Config règles.

Pour plus d’informations, consultez Capacité de mise à l’échelle d’une fonction Lambda.

c18d2gz181

AWS Config Règle gérée : lambda-concurrency-check

Jaune : aucune limite de simultanéité n'est configurée pour la fonction Lambda.

Assurez-vous que la simultanéité est configurée pour vos fonctions Lambda. La configuration d'une limite de simultanéité pour vos fonctions Lambda permet de garantir que celles-ci traitent les demandes de manière fiable et prévisible. Une limite de simultanéité réduit le risque que votre fonction soit débordée en raison d'une augmentation soudaine du trafic.

Pour plus d'informations, voir Configuration de la simultanéité réservée.

Vérifie la présence de problèmes à haut risque (HRIs) pour vos charges de travail dans le pilier performance. Cette vérification est basée sur vos commentaires AWS-Well Architected. Les résultats de la vérification varient selon que vous avez terminé ou non l'évaluation de la charge de travail avec AWS Well-Architected.

Wxdfp4B1L2

AWS Well-Architected a détecté des problèmes à haut risque lors de l'évaluation de votre charge de travail. Ces problèmes offrent la possibilité de réduire les risques et d'économiser de l'argent. Connectez-vous à l'outil AWS Well-Architected afin de passer en revue vos réponses et d'intervenir pour résoudre vos problèmes actifs.

Vérifie les CloudFront distributions Amazon pour détecter les noms de domaine alternatifs (CNAMES) dont DNS les paramètres sont mal configurés.

Si une CloudFront distribution inclut des noms de domaine alternatifs, la DNS configuration des domaines doit acheminer DNS les requêtes vers cette distribution.

N420c450f2

Mettez à jour la DNS configuration pour acheminer les DNS requêtes vers la CloudFront distribution ; voir Utilisation de noms de domaine alternatifs (CNAMEs).

Si vous utilisez Amazon Route 53 comme DNS service, consultez Acheminer le trafic vers une distribution CloudFront Web Amazon en utilisant votre nom de domaine. Si le délai de vérification a expiré, essayez d'actualiser la vérification.

Guide CloudFront du développeur Amazon

Vérifie les cas dans lesquels le transfert de données depuis les compartiments Amazon Simple Storage Service (Amazon S3) pourrait être accéléré en utilisant CloudFront Amazon, AWS le service mondial de diffusion de contenu.

Lorsque vous configurez CloudFront la diffusion de votre contenu, les demandes relatives à votre contenu sont automatiquement acheminées vers l'emplacement périphérique le plus proche où le contenu est mis en cache. Ce routage permet de diffuser du contenu à vos utilisateurs avec les meilleures performances possibles. Un ratio élevé de données transférées par rapport aux données stockées dans le compartiment indique que vous pourriez bénéficier de l'utilisation d'Amazon CloudFront pour fournir les données.

796d6f3D83

Envisagez de l'utiliser CloudFront pour de meilleures performances. Consultez les détails CloudFront du produit Amazon.

Si les données transférées sont supérieures ou égales à 10 To par mois, consultez CloudFront les tarifs Amazon pour découvrir les économies possibles.

Vérifie les en-têtes de HTTP demande CloudFront actuellement reçus du client et les transmet à votre serveur d'origine.

Certains en-têtes, tels que date ou user-agent, réduisent considérablement le taux de réussite du cache (la proportion de demandes traitées à partir d'un cache CloudFront périphérique). Cela augmente la charge sur votre origine et réduit les performances, car vous CloudFront devez transmettre davantage de demandes à votre origine.

N415c450f2

Jaune : un ou plusieurs en-têtes de requête renvoyés CloudFront vers votre source peuvent réduire considérablement le taux de réussite de votre cache.

Déterminez si les en-têtes de requête offrent suffisamment d'avantages pour justifier l'impact négatif sur le taux d'accès au cache. Si votre origine renvoie le même objet quelle que soit la valeur d'un en-tête donné, nous vous recommandons de ne pas configurer CloudFront pour transférer cet en-tête vers l'origine. Pour plus d'informations, voir Configuration de la mise CloudFront en cache des objets en fonction des en-têtes de demande.

Vérifie les instances Amazon Elastic Compute Cloud (AmazonEC2) qui étaient en cours d'exécution à tout moment au cours des 14 derniers jours. Une alerte est envoyée si CPU l'utilisation quotidienne a été supérieure à 90 % pendant quatre jours ou plus.

Une utilisation élevée et constante peut indiquer des performances optimisées et stables. Cependant, il peut également indiquer qu'une application ne dispose pas de ressources suffisantes. Pour obtenir CPU des données d'utilisation quotidiennes, téléchargez le rapport relatif à cette vérification.

ZRxQlPsb6c

Jaune : une instance a enregistré un taux d'CPUutilisation moyen quotidien supérieur à 90 % au cours d'au moins 4 des 14 jours précédents.

Pensez à ajouter d'autres instances. Pour plus d'informations sur la mise à l'échelle du nombre d'instances en fonction de la demande, consultez Qu'est-ce qu'Amazon EC2 Auto Scaling ?