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.
S'assurer que vous disposez de suffisamment de mémoire pour créer un instantané Valkey ou Redis OSS
Instantanés et synchronisations dans Valkey 7.2 et versions ultérieures, et Redis OSS version 2.8.22 et versions ultérieures
Valkey prend en charge par défaut les instantanés et les synchronisations. Redis OSS 2.8.22 introduit un processus de sauvegarde sans fourche qui vous permet d'allouer une plus grande partie de votre mémoire à l'utilisation de votre application sans augmenter l'utilisation des swap lors des synchronisations et des sauvegardes. Pour de plus amples informations, veuillez consulter Implémentation de la sauvegarde et de la synchronisation.
OSSInstantanés et synchronisations Redis antérieurs à la version 2.8.22
Lorsque vous travaillez avec ElastiCache (RedisOSS), Redis OSS appelle une commande d'écriture en arrière-plan dans un certain nombre de cas :
Lorsque de la création d'un instantané pour une sauvegarde.
Lors de la synchronisation de réplicas avec le réplica principal dans un groupe de réplication.
Lorsque vous activez la fonctionnalité d'ajout de fichier uniquement (AOF) pour Redis. OSS
Lors la promotion d'un réplica en tant que maître (qui entraîne une synchronisation du réplica principal/réplica).
Chaque fois que Redis OSS exécute un processus d'écriture en arrière-plan, vous devez disposer de suffisamment de mémoire disponible pour faire face à la surcharge du processus. Si vous ne disposez pas de suffisamment de mémoire, le processus échoue. Pour cette raison, il est important de choisir un type d'instance de nœud disposant de suffisamment de mémoire lors de la création de votre OSS cluster Redis.
Processus d'écriture en arrière-plan et utilisation de la mémoire avec Valkey et Redis OSS
Chaque fois qu'un processus d'écriture en arrière-plan est appelé, Valkey et Redis modifient OSS son processus (n'oubliez pas que ces moteurs sont à thread unique). Un fork conserve vos données sur le disque dans un fichier instantané Redis OSS .rdb. L'autre fork traite toutes les opérations de lecture et d'écriture. Pour garantir que votre instantané est un point-in-time instantané, toutes les mises à jour et tous les ajouts de données sont écrits dans une zone de mémoire disponible distincte de la zone de données.
Tant que vous disposez de suffisamment de mémoire pour enregistrer toutes les opérations d'écriture pendant le stockage des données sur le disque, vous n'aurez pas de problème de mémoire insuffisante. Vous risquez d'avoir des problèmes de mémoire insuffisante si l'une des affirmations suivantes est vraie :
-
Votre application effectue de nombreuses opérations d'écriture, nécessitant une grande quantité de mémoire disponible pour accepter les données mises à jour ou nouvelles.
-
Vous disposez de très peu de mémoire disponible pour pouvoir écrire de nouvelles données ou mettre à jour des données.
-
Stocker durablement sur le disque votre jeu de données volumineux prend du temps car cela nécessite un grand nombre d'opérations d'écriture.
Le schéma suivant représente l'utilisation de la mémoire lors de l'exécution d'un processus d'écriture en arrière-plan.
Pour obtenir des informations sur l'impact d'une sauvegarde sur les performances, consultez Impact sur les performances des sauvegardes de clusters auto-conçus.
Pour plus d'informations sur les régions et les zones de disponibilité, consultez Choix des régions et des zones de disponibilité pour ElastiCache.
Eviter tout dépassement de mémoire lors de l'exécution d'un processus d'écriture en arrière-plan
Chaque fois qu'un processus d'écriture en arrière-plan tel que BGSAVE
ou BGREWRITEAOF
est appelé, pour éviter l'échec du processus, vous devez disposer de plus de mémoire disponible que celle qui sera consommée par les opérations d'écriture pendant le processus. Dans le pire des cas, pendant l'opération d'écriture en arrière-plan, chaque enregistrement est mis à jour et de nouveaux enregistrements sont ajoutés au cache. reserved-memory-percent
Pour cette raison, nous vous recommandons de définir la valeur 50 (50 %) pour les OSS versions de Redis antérieures à la version 2.8.22, ou 25 (25 %) pour Valkey et toutes les versions Redis OSS 2.8.22 et ultérieures.
La valeur maxmemory
indique que la mémoire dont vous disposez pour le traitement des données et la surcharge opérationnelle. Etant donné que vous ne pouvez pas modifier le paramètre reserved-memory
dans le groupe de paramètres par défaut, vous devez créer un groupe de paramètres personnalisés pour le cluster. La valeur par défaut reserved-memory
est 0, ce qui permet OSS à Redis de consommer toute la mémoire maximale associée aux données, laissant potentiellement trop peu de mémoire pour d'autres utilisations, telles qu'un processus d'écriture en arrière-plan. Pour les valeurs maxmemory
par type d'instance de nœud, consultez Paramètres spécifiques au type de OSS nœud Redis.
Vous pouvez également utiliser le reserved-memory
paramètre pour réduire la quantité de mémoire utilisée sur le boîtier.
Pour plus d'informations sur les paramètres spécifiques à Valkey et Redis dans, consultez. ElastiCache Paramètres Valkey et Redis OSS
Pour plus d'informations sur la création et la modification des groupes de paramètres, consultez Création d'un groupe ElastiCache de paramètres et Modification d'un groupe ElastiCache de paramètres.