HCL Commerce Version 9.1.9.0

mantenimiento

implementa una serie de procesos de mantenimiento necesarios.

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, ya que 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.

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.

Consulte Mantenimiento de memoria caché de HCL para ver las últimas configuraciones disponibles. En comparación con los últimos disponibles, las diferencias clave son las siguientes:

  • En la versión 9.1.9, el mantenimiento de memoria baja utiliza la configuración disponible más rápida (cleanupRate) para el mantenimiento caducado. En versión 9.1.10+ el mantenimiento de memoria baja tiene su propia configuración.

  • El mantenimiento de inactividad no está disponible en la versión 9.1.9.

Procesos de mantenimiento autoajuste

Todos los procesos de mantenimiento implementan una técnica similar para autoajustar la velocidad de mantenimiento. La ejecución del mantenimiento demasiado rápidamente 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 eliminan, 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
Este es el número máximo de entradas de memoria caché que se inspeccionarán y procesarán mediante un script 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 12 minutos, utilizará la configuración de mantenimiento para objetos de 10 a 13 minutos, que se limpia a una velocidad de 20/ segundo.
newerThan:  300 secs (  5 mins) inLUA:  1 pipeline:  1 delayMs:  60000 -- speed:   0.02/sec,       1/min
newerThan:  600 secs ( 10 mins) inLUA:  2 pipeline:  5 delayMs:   1000 -- speed:     10/sec,     600/min
newerThan:  780 secs ( 13 mins) inLUA:  2 pipeline:  5  delayMs:   500 -- speed:     20/sec,   1,200/min
newerThan:  900 secs ( 15 mins) inLUA:  3 pipeline:  5 delayMs:    300 -- speed:     50/sec,   3,000/min
newerThan: 1200 secs ( 20 mins) inLUA:  3 pipeline: 10 delayMs:    250 -- speed:    120/sec,   7,200/min
newerThan: ~ ALL ~              inLUA:  5 pipeline: 10 delayMs:    200 -- speed:    250/sec,  15,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 (onlineInactiveEntriesMaintenance)

con Redis no funciona bien cuando la memoria está llena. Los procesos, incluidos los procesos de mantenimiento, pueden fallar con errores de memoria "mandato no permitido cuando se utiliza memoria > 'maxmemory'". Para evitar esta situación, supervisa el porcentaje de memoria utilizada y desencadena un proceso de mantenimiento de memoria bajo 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.
Tasas de limpieza de mantenimiento de memoria baja
Las tasas de limpieza de mantenimiento de memoria baja se basan en la configuración de mantenimiento caducado . El mantenimiento de memoria baja utiliza la configuración más rápida disponible para el mantenimiento caducado, que actualmente es de 250 claves/s o 15 000 claves/ mínimo.

La configuración predeterminada de 250 claves/segundo puede no ser lo suficientemente rápida para determinados entornos de producción y es posible que deba actualizarse. Consulte Actualización de los valores de mantenimiento predeterminados para obtener detalles.

Actualización de los valores de mantenimiento predeterminados

Aunque debido a la naturaleza de autoajuste de los scripts, es posible que el ajuste no sea necesario, las configuraciones se pueden cambiar 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:
         ...

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.