Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Cet article décrit les meilleures pratiques pour la gestion de la mémoire dans Azure Cache pour Redis.
Choisir la stratégie d’éviction appropriée
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, ce qui signifie que seules les clés qui ont une valeur de durée de vie (TTL) définie avec une commande comme EXPIRE sont éligibles à l’éviction. Si aucune clé n’a de valeur TTL, le système ne supprime aucune clé. Si vous souhaitez que le système autorise l’expulsion de n’importe quelle clé en cas de pression mémoire, envisagez la stratégie allkeys-lru.
Définir une date d’expiration des clés
Une éviction à cause d’une sollicitation de la mémoire peut entraîner une charge plus importante sur votre serveur. Définissez une valeur d’expiration sur vos clés pour supprimer les clés de manière proactive au lieu d’attendre qu’il y ait une pression de mémoire. Pour plus d’informations, consultez la documentation relative aux commandes Redis EXPIRE et EXPIREAT .
Réduire la fragmentation de la mémoire
Les valeurs de clé volumineuses peuvent laisser la mémoire fragmentée lors de l’éviction et entraîner une utilisation élevée de la mémoire et une charge de serveur.
Surveiller l’utilisation de la mémoire
Surveillez l’utilisation de la mémoire pour vous assurer que vous n’avez pas de mémoire insuffisante. Créez des alertes pour vous permettre de mettre à l’échelle votre cache avant que des problèmes se produisent.
Configurer le paramètre maxmemory-reserved
Configurez le paramètre maxmemory-reserved pour améliorer la réactivité du système. Les paramètres de réservation suffisants sont particulièrement importants pour les charges de travail nécessitant beaucoup d’écriture, ou si vous stockez des valeurs de 100 Ko ou plus dans votre cache.
Le
maxmemory-reservedparamètre configure la quantité de mémoire, en Mo par instance d’un cluster, réservée aux opérations non mises en 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.Le
maxfragmentationmemory-reservedparamètre configure la quantité de mémoire, en Mo par instance d’un cluster, réservée pour prendre en charge 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 à ces opérations, elle n’est pas disponible pour stocker des données mises en cache. Par défaut, lorsque vous créez un cache, environ 10% de la mémoire disponible est réservée à maxmemory-reserved, et un autre 10% est réservé à maxfragmentationmemory-reserved. Vous pouvez augmenter les quantités réservées si vous avez des charges d'écriture intensives.
Les plages autorisées pour maxmemory-reserved et pour maxfragmentationmemory-reserved 10%-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 %.
Quand 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 maxmemory-reserved la valeur est de 3 Go sur un cache de 6 Go et que vous effectuez une mise à l’échelle vers un cache de 12 Go, le paramètre est automatiquement mis à jour sur 6 Go pendant la mise à l’échelle. Si vous effectuez un scale-down, l’inverse se produit.
Considérez comment la modification d'une valeur de réservation de mémoire maxmemory-reserved ou maxfragmentationmemory-reserved pourrait affecter un cache avec une grande quantité de données déjà en cours d'exécution. Par exemple, si vous avez un cache de 53 Go avec les valeurs réservées définies sur les 10% minimums, la mémoire maximale disponible pour le système est d’environ 42 Go. Si l'une ou l'autre de vos valeurs actuelles used_memory ou used_memory_rss est plus élevée que 42 Go, le système doit évacuer les données jusqu’à ce que les deux valeurs used_memory et used_memory_rss soient inférieurs à 42 Go.
L'expulsion peut augmenter la charge du serveur et la fragmentation de la mémoire. 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.
Remarque
Lorsque vous mettez à l’échelle par programmation un cache à l’aide d’Azure PowerShell, Azure CLI ou de l’API REST, tous les paramètres maxmemory-reserved ou maxfragmentationmemory-reserved inclus sont ignorés en tant que partie de la requête de mise à jour. Seul votre changement d’échelle est pris en compte. Vous pouvez mettre à jour les paramètres de mémoire une fois l’opération de mise à l’échelle terminée.