Partager via

Gestion de la mémoire

  • Article

Stratégie d’éviction

Choisissez une stratégie d’éviction appropriée pour votre application. La stratégie par défaut pour Azure Cache pour Redis est volatile-lru, qui spécifie que seules les clés dont la durée de vie a été définie avec une commande telle que EXPIRE peuvent être supprimées. Si aucune clé n’a une valeur de durée de vie, le système ne supprime pas de clés. Si vous souhaitez que le système autorise la suppression de toutes les clés dans des conditions de forte sollicitation de la mémoire, choisissez plutôt la stratégie allkeys-lru.

Expiration des clés

Définissez le délai d’expiration de vos clés. L’expiration entraîne la suppression des clés de manière proactive, et non uniquement en cas de forte sollicitation de la mémoire. Lorsqu’une opération de suppression doit avoir lieu en raison d’une forte sollicitation de la mémoire, une charge supplémentaire sur votre serveur peut en résulter. Pour plus d’informations, consultez la documentation concernant les commandes EXPIRE et EXPIREAT.

Réduire la fragmentation de la mémoire

Les valeurs élevées peuvent faire en sorte que la mémoire soit fragmentée lors de la suppression et peuvent entraîner une utilisation élevée de la mémoire et une charge du serveur.

Surveiller l’utilisation de la mémoire

Ajoutez une surveillance de l’utilisation de la mémoire pour vous assurer de ne pas être à court de mémoire et de pouvoir mettre à l’échelle votre cache avant de rencontrer des problèmes.

Configurer le paramètre maxmemory-reserved

Configurez le paramètre maxmemory-reserved afin d’améliorer la réactivité du système :

  • Une valeur suffisante de réservation est particulièrement importante pour les charges de travail nécessitant beaucoup d’écritures, ou si vous stockez des volumes de données de 100 Ko ou plus dans votre cache. Par défaut, quand vous créez un cache, environ 10 % de la mémoire disponible est réservé pour maxmemory-reserved. Un autre 10 % est réservé pour maxfragmentationmemory-reserved. Vous pouvez augmenter la quantité réservée si vous avez des charges avec beaucoup d’écritures.

  • Le paramètre maxmemory-reserved détermine la quantité de mémoire (en mégaoctets par instance dans un cluster) réservée à des opérations non-cache telles que la réplication pendant le basculement. La définition de ce paramètre vous permet d’avoir une expérience de serveur Redis plus cohérente lorsque votre charge varie. Cette valeur doit être plus élevée pour les charges de travail qui écrivent de grandes quantités de données. Lorsque la mémoire est réservée pour ces opérations, elle n’est pas disponible pour le stockage des données mises en cache. La plage autorisée pour maxmemory-reserved est comprise entre 10 % et 60 % de maxmemory. Si vous essayez de définir ces valeurs en dessous de 10 % ou au-dessus de 60 %, elles sont réévaluées et définies sur la valeur minimale de 10 % et la valeur maximale de 60 %. Les valeurs sont affichées en mégaoctets.

  • Le paramètre maxfragmentationmemory-reserved détermine la quantité de mémoire (en mégaoctets par instance dans un cluster) réservée pour la fragmentation de la mémoire. La définition de ce paramètre vous permet d’avoir un serveur Redis plus cohérent lorsque le cache est plein ou presque, et que le taux de fragmentation est élevé. Lorsque la mémoire est réservée pour ces opérations, elle n’est pas disponible pour le stockage des données mises en cache. La plage autorisée pour maxfragmentationmemory-reserved est comprise entre 10 % et 60 % de maxmemory. Si vous essayez de définir ces valeurs en dessous de 10 % ou au-dessus de 60 %, elles sont réévaluées et définies sur la valeur minimale de 10 % et la valeur maximale de 60 %. Les valeurs sont affichées en mégaoctets.

  • Un aspect à prendre en compte quand vous choisissez une nouvelle valeur de réservation de mémoire (maxmemory-reserved ou maxfragmentationmemory-reserved) est la manière dont ce changement peut affecter un cache déjà en cours d’exécution et qui contient de grandes quantités de données. Par exemple, si vous disposez d’un cache de 53 Go avec 49 Go de données, que vous modifiez la valeur de réservation en la définissant sur 8 Go, la mémoire maximale disponible pour le système chute à 45 Go. Si vos valeurs used_memory ou used_memory_rss actuelles sont supérieures à la nouvelle limite de 45 Go, le système doit supprimer des données jusqu’à ce que les valeurs used_memory et used_memory_rss soient toutes deux inférieures à 45 Go. La suppression de données peut augmenter la fragmentation de la charge et de la mémoire du serveur. Pour plus d’informations sur les métriques de cache tel que used_memory et used_memory_rss, consultez Créer vos propres métriques.

Notes

Lorsque vous mettez à l’échelle un cache, les paramètres maxmemory-reserved et maxfragmentationmemory-reserved sont automatiquement mis à l’échelle en fonction de la taille du cache. Par exemple, si le paramètre maxmemory-reserved a la valeur 3 Go sur un cache de 6 Go et que vous augmentez à 12 Go l’échelle du cache, le paramètre est automatiquement mis à jour à 6 Go pendant la mise à l’échelle. Lorsque vous réduisez l’échelle, l’inverse se produit. Quand vous faites un scale-up ou un scale-down d’un cache programmatiquement, avec PowerShell, CLI ou l’API Rest, les paramètres maxmemory-reserved ou maxfragmentationmemory-reserved sont ignorés dans le cadre de la demande de mise à jour. Seul votre changement d’échelle est respecté. Vous pouvez mettre à jour ces paramètres de mémoire une fois l’opération de mise à l’échelle terminée.

Étapes suivantes