mantenimiento

Para dar soporte a características como la invalidación mediante ID de dependencia, mantiene la información de metadatos para cada entrada de memoria caché. Redis no puede caducar o desalojar estos metadatos, porque esto provocaría incoherencias como invalidaciones fallidas.

implementa una serie de procesos en segundo plano para mantener la información de metadatos.

Mantenimiento caducado: Elimina metadatos para objetos que han caducado.
Mantenimiento de memoria baja: Se desencadena cuando la memoria de Redis está a punto de agotarse y elimina las entradas de memoria caché que caducan más pronto para liberar memoria.
Mantenimiento de inactividad: Mantenimiento opcional que se puede utilizar para eliminar entradas de memoria caché inactivas.

Para obtener más detalles, consulte Gestión de memoria en Redis.

Los trabajos de mantenimiento pueden añadir sobrecarga a los servidores de Redis. Es importante que los entornos de prueba de rendimiento simulen con precisión entornos de producción, realizando los procesos de mantenimiento de forma similar. Por ejemplo, si el entorno de producción normalmente llena la memoria de Redis, el entorno de rendimiento debe hacer lo mismo. Es posible que las pruebas cortas (por ejemplo, una hora de duración) no sean lo suficientemente largas para simular condiciones de proceso de mantenimiento caducadas e inactividad

Procesos de mantenimiento autoajuste

Todos los procesos de mantenimiento implementan una técnica similar para autoajustar la velocidad de mantenimiento. La ejecución de un mantenimiento demasiado rápido puede afectar al rendimiento, mientras que si se realiza demasiado lentamente, se pueden añadir datos nuevos a una velocidad más rápida de la que se elimina, lo que provoca situaciones de falta de memoria (OOM). Por ejemplo, el mantenimiento caducado ajusta la velocidad del mantenimiento teniendo en cuenta el tiempo transcurrido desde la caducidad de las entradas de memoria caché caducadas más antiguas. Si aumenta el tiempo desde la caducidad, significa que el mantenimiento caducado no se ejecuta a una velocidad lo suficientemente rápida, y la velocidad aumenta.

Los procesos de mantenimiento también tienen configuraciones para determinar cuántas entradas de memoria caché se eliminan a la vez. Esto es necesario porque Redis tiene una sola hebra y una operación de mantenimiento grande puede bloquear Redis.

numCacheIdPerLUACall: El número máximo de entradas de memoria caché que inspeccionará y procesará un script de LUA. El aumento del número acelera el mantenimiento, pero también puede bloquear la hebra Redis durante un periodo más largo.
numLUACallsInPipeline: El número de scripts LUA que se envían juntos como un lote. La hebra Redis solo se bloquea durante cada ejecución de script individual.

LUA es un lenguaje de scripts soportado por Redis para operaciones del lado del servidor. Los scripts LUA son compactos y bloquean.

Debido a la naturaleza autoajuste de los procesos de mantenimiento, el ajuste no suele ser necesario, pero las pruebas de rendimiento son fundamentales para confirmar que se ejecutan a velocidades óptimas.

Mantenimiento caducado (onlineExpiredEntriesMaintenance)

Aunque Redis elimina automáticamente los valores almacenados en memoria caché caducados de la memoria, el proceso de mantenimiento caducado es responsable de eliminar las entradas de memoria caché caducadas de los metadatos (ID de dependencia). Este proceso se ejecuta desde todos los pods y la velocidad viene determinada por la antigüedad del mantenimiento pendiente de entrada caducado más antiguo.

Tasas de limpieza de mantenimiento caducado

La velocidad de mantenimiento se ajusta en función de la edad de la entrada caducada más antigua. Por ejemplo, si el proceso de mantenimiento encuentra entradas de memoria caché que han caducado durante siete minutos, utilizará la configuración de mantenimiento para los objetos de 5 a 8 minutos, que se limpia a una velocidad de 20/segundo.

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

Para obtener detalles sobre la actualización de la configuración, consulte Actualización de los valores de mantenimiento predeterminados.

Detalles de mantenimiento caducados de la memoria caché de HCL - Panel remoto:

Mantenimiento de memoria baja (onlineLowMemoryEntriesMaintenance)

con Redis no funciona bien cuando la memoria está llena. Los procesos, incluidos los procesos de mantenimiento, pueden fallar con el error de memoria "mandato no permitido cuando se utiliza memoria > 'maxmemory'". Para evitar esta situación, supervisa el porcentaje de memoria utilizada y desencadena el proceso de mantenimiento de memoria baja para reducir el tamaño de cada memoria caché. El proceso elimina los valores almacenados en memoria caché y los metadatos de entrada de memoria caché asociados. Las claves seleccionadas para su eliminación son aquellas que van a caducar antes. El trabajo de mantenimiento de memoria baja está planificado desde todos los pods, pero solo puede estar activo desde un solo contenedor en un momento dado.

Mantenimiento de memoria baja en Redis enterprise: Debido a las diferencias en la arquitectura, Redis Enteprise no hace que las estadísticas de memoria utilizada estén disponibles para la aplicación. Este es el desencadenante que el proceso de mantenimiento de memoria baja utiliza para determinar cuándo y cuánto mantenimiento es necesario. Como resultado, con Redis Enterprise, la configuración softMaxSize debe configurarse manualmente para cada memoria caché para definir un tamaño máximo en número de entradas.

Configuraciones predeterminadas de mantenimiento de memoria baja

La configuración predeterminada es. Para obtener detalles sobre la actualización de la configuración, consulte Actualización de los valores de mantenimiento predeterminados.


Configuración	Valor predeterminado	Utilización
intervalSecs	120	Intervalo en el que se ejecuta el trabajo de mantenimiento de memoria baja en cada pod para comprobar las condiciones de memoria.
maxMemoryPercentage	93	Si el porcentaje de memoria utilizado es igual o superior a esta configuración, debe ejecutarse el proceso de mantenimiento.
MaintenancePercentageBuffer	5	El porcentaje de la memoria caché que se elimina. Por ejemplo, si maxMemoryPercentage es 93% y maintenancePercentageBuffer es 5%, la memoria de destino utilizada después del mantenimiento es 88%.
putOperationPausePercentage	5	Este porcentaje se añade a maxMemoryPercentage. Por ejemplo, si maxMemoryPercentage es 93% y putOperationPausePercentage es 5%, cuando la memoria utilizada alcanza el 98%, las memorias caché dejan de insertarse en la memoria caché remota para permitir que el mantenimiento se ponga al día.
softMaxSize	-1	Se utiliza para establecer un tamaño máximo en entradas. Se puede utilizar en combinación con maxMemoryPercentage.
softMaxSizeAsPercentFull	93	Se utiliza para correlacionar el tamaño de memoria caché actual en entradas para softMaxSize con un cleanupRate que se especifica como un porcentaje de memoria caché. En este caso, cuando el tamaño de memoria caché es igual a softMaxSize, se supone que el % utilizado es 93%. Esto hace los cálculos equivalentes a maxMemoryPercentage.

Tasas de limpieza de mantenimiento de memoria baja

La velocidad de mantenimiento se ajusta en función del porcentaje de memoria libre. Inicio de mantenimiento a 500/ seg. Si la memoria alcanza el 100%, el mantenimiento podría ejecutarse hasta 4000/ seg.

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

Mantenimiento de inactividad (onlineInactiveEntriesMaintenance)

La configuración de inactividad permite a realizar un seguimiento y expulsar entradas que no están siendo reutilizadas. Al eliminar entradas desocupadas antes de su tiempo de caducidad, se reduce el uso total de memoria caché, lo que ayuda a que las memorias caché se ejecuten de forma más eficaz.

El mantenimiento de inactividad está inhabilitado de forma predeterminada. Debe habilitarse especificando un umbral de inactividad en minutos (inactivityMins) para cada memoria caché remota. Para obtener detalles, consulte Configuraciones de ajuste de memoria caché remota.

El mantenimiento de inactividad se ejecuta desde todos los contenedores (simultáneamente). La tasa predeterminada de limpieza se define de la siguiente manera:

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

Actualización de los valores de mantenimiento predeterminados

Aunque el ajuste puede no ser necesario debido a la naturaleza de autoajuste de los scripts, puede cambiar las configuraciones actualizando los archivos de configuración YAML de memoria caché. Las configuraciones se pueden cambiar a nivel de memoria caché o para todas las memorias caché utilizando defaultCacheConfig:

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

Los enlaces siguientes incluyen fragmentos de código YAML para las configuraciones predeterminadas (de inicio):

Para configuraciones de lista como cleanupRate, las personalizaciones deben volver a definir la lista completa en lugar de elementos individuales.