Maintenance de

Pour prendre en charge des fonctions telles que l'invalidation par ID de dépendance, le gère les informations de métadonnées pour chaque entrée de cache. Ces métadonnées ne peuvent pas expirer ou être expulsées par Redis, car cela entraînerait des incohérences telles que des invalidations manquées.

implémente un certain nombre de processus en arrière-plan pour gérer les informations de métadonnées.

Maintenance arrivée à expiration: Supprime les métadonnées des objets arrivés à expiration.
Mmaintenance de mémoire faible: Se déclenche lorsque la mémoire Redis est presque saturée et supprime les entrées de cache qui expirent le plus tôt pour libérer de la mémoire.
Maintenance d'inactivité: Maintenance facultative pouvant être utilisée pour supprimer les entrées de cache inactives.

Pour plus de détails, voir Gestion de la mémoire dans Redis.

Les travaux de maintenance peuvent ajouter de la surcharge aux serveurs Redis. Il est important que les environnements de test de performances simulent précisément les environnements de production, en exerçant les processus de maintenance de la même manière. Par exemple, si l'environnement de production remplit généralement la mémoire Redis, l'environnement de performances doit faire de même. Les tests courts (par exemple, d'une durée d'une heure) peuvent ne pas être assez longs pour simuler des conditions de traitement de maintenance d'inactivité et expirées

Processus de maintenance automatiquement ajusté

Tous les processus de maintenance implémentent une technique similaire pour ajuster automatiquement la vitesse de maintenance. L'exécution trop rapide de la maintenance peut avoir un impact sur les performances, tandis que si elle est effectuée trop lentement, de nouvelles données peuvent être ajoutées à une vitesse plus rapide qu'elle n'est supprimée, ce qui entraîne des situations de manque de mémoire (OOM). Par exemple, la maintenance expirée ajuste la vitesse de maintenance en tenant compte du délai écoulé depuis l'expiration des entrées de cache arrivées à expiration les plus anciennes. Si le délai depuis l'expiration augmente, cela signifie que la maintenance expirée ne fonctionne pas à un débit assez rapide et que la vitesse est augmentée.

Les processus de maintenance ont également des configurations pour déterminer le nombre d'entrées de cache supprimées en même temps. Cette opération est requise, car Redis est à unité d'exécution unique et une opération de maintenance importante peut bloquer Redis.

numCacheIdPerLUACall: Nombre maximal d'entrées de cache qui seront inspectées et traitées par un script LUA. L'augmentation du nombre accélère la maintenance, mais peut également bloquer l'unité d'exécution Redis pendant une plus longue période.
numLUACallsInPipeline: Nombre de scripts LUA envoyés ensemble en tant que lot. L'unité d'exécution Redis n'est verrouillée que lors de chaque exécution de script individuel.

LUA est un langage de script pris en charge par Redis pour les opérations côté serveur. Les scripts LUA sont atomiques et bloquants.

En raison de la nature auto-ajustée des processus de maintenance, le réglage ne doit généralement pas être requis, mais les tests de performances sont essentiels pour confirmer qu'ils s'exécutent à des vitesses optimales.

Maintenance arrivée à expiration (onlineExpiredEntriesMaintenance)

Alors que Redis supprime automatiquement de la mémoire les valeurs en cache arrivées à expiration, le processus de maintenance arrivé à expiration est chargé de supprimer les entrées de cache arrivées à expiration des métadonnées (ID de dépendance). Ce processus s'exécute à partir de tous les pods et la vitesse est déterminée par l'âge de l'entrée expirée la plus ancienne en attente de maintenance.

Taux de nettoyages de maintenance arrivés à expiration

La vitesse de maintenance s'ajuste en fonction de l'âge de l'entrée arrivée à expiration la plus ancienne. Par exemple, si le processus de maintenance trouve des entrées de cache arrivées à expiration depuis sept minutes, il utilisera la configuration de maintenance pour les objets de 5 à 8 minutes, ce qui nettoie à une vitesse de 20/seconde.

newerThan:  180 secs (  3 mins) inLUA:  1 pipeline:  1 delayMs:  60000 -- speed:   0.02/sec,       1/min
newerThan:  300 secs (  5 mins) inLUA:  2 pipeline:  5 delayMs:    500 -- speed:     20/sec,   1,200/min
newerThan:  480 secs (  8 mins) inLUA:  3 pipeline: 10 delayMs:    250 -- speed:    120/sec,   7,200/min
newerThan:  900 secs ( 15 mins) inLUA:  5 pipeline: 10 delayMs:    200 -- speed:    250/sec,  15,000/min
newerThan: 1800 secs ( 30 mins) inLUA:  5 pipeline: 10 delayMs:    100 -- speed:    500/sec,  30,000/min
newerThan: ~ ALL ~              inLUA:  5 pipeline: 10 delayMs:     50 -- speed:  1,000/sec,  60,000/min

Pour plus d'informations sur la mise à jour de la configuration, voir Mise à jour des valeurs de maintenance par défaut.

Détails de maintenance arrivée à expiration à partir du tableau de bord HCL Cache - Remote :

Maintenance de mémoire faible (onlineLowMemoryEntriesMaintenance)

avec Redis ne fonctionne pas correctement lorsque la mémoire est saturée. Les processus, y compris les processus de maintenance, peuvent échouer avec l'erreur de mémoire "commande non autorisée lorsque la mémoire utilisée > 'maxmemory'". Pour éviter cette situation, surveille le pourcentage de mémoire utilisée et déclenche le traitement de maintenance de mémoire faible pour réduire la taille de chaque cache. Le traitement supprime les valeurs mises en cache et leurs métadonnées d'entrée de cache associées. Les clés sélectionnées pour la suppression sont celles qui expirent plus tôt. Le travail de maintenance de mémoire faible est planifié à partir de tous les pods, mais il ne peut être actif qu'à partir d'un seul conteneur à tout moment.

Maintenance de mémoire faible dans Redis Enterprise: En raison de différences d'architecture, Redis Enteprise ne met pas les statistiques de mémoire utilisées à la disposition de l'application. Il s'agit du déclencheur utilisé par le processus de maintenance de mémoire faible pour déterminer combien de maintenances sont nécessaires et quand. Par conséquent, avec Redis Enterprise, la configuration softMaxSize doit être configurée manuellement pour chaque cache afin de définir une taille maximale en nombre d'entrées.

Configurations par défaut de maintenance de mémoire faible

Les configurations par défaut sont les suivantes : Pour plus d'informations sur la mise à jour de la configuration, voir Mise à jour des valeurs de maintenance par défaut.


Configuration	Par défaut	Utilisation
intervalSecs	120	Intervalle auquel le travail de maintenance de mémoire faible s'exécute sur chaque pod pour vérifier les conditions de mémoire.
maxMemoryPercentage	93	Si le pourcentage de mémoire utilisé est supérieur ou égal à cette configuration, le processus de maintenance doit s'exécuter.
maintenancePercentageBuffer	5	Pourcentage du cache supprimé. Par exemple, si maxMemoryPercentage est de 93 % et si maintenancePercentageBuffer est de 5 %, la mémoire cible utilisée après la maintenance est de 88 %.
putOperationPausePercentage	5	Ce pourcentage est ajouté à maxMemoryPercentage. Par exemple, si maxMemoryPercentage est de 93 % et si putOperationPausePercentage est de 5 %, lorsque la mémoire utilisée atteint 98 %, les caches cessent de s'insérer dans le cache distant pour permettre le rattrapage de la maintenance.
softMaxSize	-1	Utilisé pour définir une taille maximale dans les entrées. Il peut être utilisé en combinaison avec maxMemoryPercentage.
softMaxSizeAsPercentFull	93	Utilisé pour mapper la taille de cache actuelle dans les entrées pour softMaxSize à une valeur cleanupRate spécifiée en tant que pourcentage de cache. Dans ce cas, lorsque la taille du cache est égale à softMaxSize, le % utilisé supposé est de 93 %. Cela rend les calculs équivalents à maxMemoryPercentage.

Taux de nettoyage de maintenance de mémoire faible

La vitesse de maintenance s'ajuste en fonction du pourcentage de mémoire libre. La maintenance démarre à 500/s. Si la mémoire atteint 100 %, la maintenance peut s'exécuter jusqu'à 4 000/s.

used: >= 99%  inLUA:  5 pipeline: 20 delayMs: 25 -- speed: 4,000/sec, 240,000/min
used: >= 97%  inLUA:  5 pipeline: 10 delayMs: 25 -- speed: 2,000/sec, 120,000/min
used: >= 96%  inLUA:  5 pipeline: 10 delayMs: 50 -- speed: 1,000/sec,  60,000/min
used: >= 95%  inLUA:  5 pipeline: 10 delayMs: 65 -- speed:   769/sec,  46,154/min
used: >=  0%  inLUA:  5 pipeline:  5 delayMs: 50 -- speed:   500/sec,  30,000/min

Maintenance de l'inactivité (onlineInactiveEntriesMaintenance)

La configuration de l'inactivité permet à de suivre et d'évincer les entrées qui ne sont pas réutilisées. En supprimant les entrées inactives avant leur heure d'expiration, l'utilisation totale de la mémoire cache est réduite, ce qui aide les caches à s'exécuter plus efficacement.

La maintenance de l'inactivité est désactivée par défaut. Elle doit être activée en spécifiant un seuil d'inactivité en minutes (inactivityMins) pour chaque cache distant. Pour plus d'informations, voir Configurations du réglage du cache à distance.

La maintenance de l'inactivité s'exécute à partir de tous les conteneurs (simultanément). Le taux de nettoyage par défaut est défini comme suit :

newerThan:  180 secs (  3 mins) inLUA:  1 pipeline:  1 delayMs:  60000 -- speed:   0.02/sec,       1/min
newerThan:  300 secs (  5 mins) inLUA:  2 pipeline:  5 delayMs:    500 -- speed:     20/sec,   1,200/min
newerThan:  480 secs (  8 mins) inLUA:  3 pipeline: 10 delayMs:    250 -- speed:    120/sec,   7,200/min
newerThan:  900 secs ( 15 mins) inLUA:  5 pipeline: 10 delayMs:    200 -- speed:    250/sec,  15,000/min
newerThan: 1800 secs ( 30 mins) inLUA:  5 pipeline: 10 delayMs:    100 -- speed:    500/sec,  30,000/min
newerThan: ~ ALL ~              inLUA:  5 pipeline: 10 delayMs:     50 -- speed:  1,000/sec,  60,000/min

Mise à jour des valeurs de maintenance par défaut

Bien que le réglage ne soit pas nécessaire en raison de la nature de réglage automatique des scripts, vous pouvez modifier les configurations en mettant à jour les fichiers de configuration YAML de cache. Les configurations peuvent être modifiées au niveau du cache ou pour tous les caches à l'aide de defaultCacheConfig :

cacheConfigs:
   defaultCacheConfig:
     remoteCache:
       onlineExpiredEntriesMaintenance:
         ...
       onlineLowMemoryMaintenance:
         ...
       onlineInactiveEntriesMaintenance:

Les liens suivants incluent des fragments YAML pour les configurations par défaut (de départ) :

Pour les configurations de liste telles que cleanupRate, les personnalisations doivent redéfinir la liste entière au lieu d'éléments individuels.