Dimensionar correctamente el parámetro «maxmemory» de Redis: reservas de memoria para datos y funcionamiento

Lo que limita realmente «maxmemory»

maxmemory publica en Redis Open Source una Umbral de desahucio No hay un límite máximo estricto para el proceso de Redis ni para su contenedor. Si el consumo relevante para la gestión de la memoria alcanza el umbral, Redis intentará eliminar claves en función de la política seleccionada. En el caso de una política sin expulsión, las órdenes de escritura que aumentan el uso de memoria pueden fallar.

El indicador used_memory abarca la memoria ocupada por Redis a través de su asignador. Esto incluye no solo los valores propiamente dichos de tu aplicación, sino también las estructuras de gestión y otras áreas de memoria de Redis. Quien calcule el límite basándose únicamente en el tamaño estimado de los datos útiles, no tendrá en cuenta esta sobrecarga.

Una parte de used_memory Queda excluido de la prueba de desahucio: mem_not_counted_for_evict destaca, en particular, los búferes temporales de replicación y AOF. No obstante, estos búferes requieren memoria física. El valor ya está en used_memory ya está incluido y, por lo tanto, no debe sumarse por segunda vez a este indicador sin comprobarlo previamente.

Esto no significa que todos los datos almacenados en los clientes o en las réplicas queden excluidos del cálculo de expulsión. Además, una sola orden de gran tamaño puede superar temporalmente el umbral de forma significativa. Si estableces maxmemory Si se alcanza el límite máximo del contenedor, no queda margen fiable para esas oscilaciones y el consumo adicional de recursos del proceso.

Por lo tanto, a la hora de planificar hay que responder por separado a dos preguntas: ¿Cuánto espacio ocupan el conjunto de datos y la sobrecarga de Redis dentro de la gestión de memoria? ¿Y cuánta reserva necesita, además, todo el entorno de ejecución? Solo la combinación de ambas perspectivas permite determinar si un valor elegido por debajo del límite real de memoria es plausible.

RSS, Allocator y picos de persistencia

Tras un pico de carga, puede used_memory disminuir, mientras que used_memory_rss sigue siendo alto: aunque Redis haya liberado memoria a través del asignador, esta no se ha devuelto necesariamente de inmediato al sistema operativo. El RSS describe la memoria residente del proceso desde el punto de vista del sistema operativo y, por lo tanto, constituye un nivel de observación diferente.

Supongamos que una caché crece considerablemente durante una acción y que, a continuación, caducan muchas claves. El hecho de que el valor de memoria de Redis sea menor no significa automáticamente que el contenedor recupere de inmediato la cantidad correspondiente de memoria libre. Por lo tanto, para el siguiente pico, la evolución del consumo real es más importante que la suposición de que la memoria liberada desaparece de inmediato.

También mem_fragmentation_ratio No se trata de un simple porcentaje de fragmentación. La proporción incluye otros componentes del proceso; para el análisis de causas, deberías tenerla en cuenta junto con los datos disponibles allocator_*-analizar las métricas y el historial de carga. A partir de una sola relación no se puede deducir una reserva válida de forma general.

En el caso de las instantáneas RDB y las reescrituras AOF, Redis crea un proceso hijo. Mediante Copy-on-Write Es posible que se necesiten páginas de memoria física adicionales si se modifican páginas durante el proceso de persistencia. Cuanto mayor y más amplia sea la carga de escritura durante ese proceso, más importante resulta tener en cuenta esta fase a la hora de planificar la capacidad.

La documentación de Redis indica que, en casos extremos, las aplicaciones con un uso intensivo de escritura pueden llegar a necesitar hasta el doble de la memoria que se utiliza normalmente. Se trata de una advertencia sobre condiciones de carga desfavorables, no de un multiplicador general. Además, no basta con sumar simplemente los valores RSS del proceso padre y del proceso hijo: las páginas compartidas se contarían varias veces; lo relevante es la supervisión adecuada del host o del contenedor.

Las réplicas necesitan presupuestos propios

Una réplica mantiene, por regla general, una copia del conjunto de datos y, para ello, necesita su propia memoria RAM. Por lo tanto, el primario y la réplica son consumidores de memoria independientes: una reserva en el primario no libera espacio en el contenedor de la réplica. Planifica cada miembro en función de su propio límite y de su consumo observado.

Por defecto, una réplica ignora su maxmemory para sus propios borrados. El nodo primario decide la eliminación de claves y replica los borrados. No obstante, los valores almacenados pueden diferir, por ejemplo, debido a diferencias en los búferes o en las estructuras de datos; por lo tanto, un mismo valor límite no garantiza una carga de trabajo idéntica.

En el caso de una Promoción La antigua réplica asume el papel de primario. Por lo tanto, comprueba no solo si dispone de espacio suficiente como copia de lectura, sino también si su límite de almacenamiento y su configuración permiten su funcionamiento como primario. Entre otros aspectos, hay que tener en cuenta la carga de escritura, las conexiones de replicación y el control de expulsión vigente en ese momento.

Desde Redis 7.0, el búfer de réplicas y la cola de replicación comparten memoria. mem_clients_slaves Por lo tanto, puede mostrar un valor nulo, aunque la replicación ocupe memoria. No interpretes este campo de forma aislada y no sumes el backlog y el búfer de réplica sin comprobar, como si fueran áreas completamente separadas.

Además del consumo de memoria, el progreso de la transmisión de datos es relevante para el funcionamiento: un retraso presenta unas características diferentes a las del tamaño de un búfer. En el artículo sobre el tema se explica cómo se pueden clasificar el estado de replicación y el retraso: Desplazamiento de replicación de Redis. No obstante, para la reserva de almacenamiento siguen siendo determinantes las curvas de consumo reales de cada instancia.

Registrar el almacenamiento en tres niveles

Para el dimensionamiento, necesitas valores de Redis y del entorno en el que se ejecuta la instancia. Los Nivel de observación determina lo que indica una cifra: la asignación del alocador, el RSS del proceso y el consumo de contenedores son magnitudes diferentes y no se pueden sumar sin más.

Con INFO memory Entre otras cosas, se leen los valores almacenados en Redis y la política configurada. MEMORY STATS Añade detalles sobre la distribución de la memoria. Ambos comandos son de lectura; los campos disponibles dependen de la versión de Redis, los permisos y el plan de alojamiento.

Para comprobar la relación temporal, comprueba además INFO persistence en cuanto a la actividad de persistencia y los valores de «copy-on-write» disponibles. INFO replication Muestra el rol y el estado de replicación. Introduce estos datos por separado para el primario y la réplica, de modo que, al realizar el análisis, se pueda identificar un cambio de rol o una sincronización.

Un único valor no refleja ni la carga de trabajo habitual ni la reserva necesaria para picos de demanda. Por eso, recopila series temporales sobre el funcionamiento normal, los picos de escritura y las ejecuciones persistentes, y asígnales el consumo del host o del contenedor observado simultáneamente. De este modo, también podrás detectar si un valor RSS elevado acompaña a una carga actual o si persiste tras un pico anterior.

Calcular un presupuesto de almacenamiento viable

El punto de partida es la que realmente surte efecto Límite de almacenamiento: En el caso de un contenedor, puede ser inferior a la memoria RAM del host. Averigua qué otros procesos y componentes del sistema consumen ese mismo límite. Lo que se les reserva no está disponible para Redis, ni para datos ni para picos de carga.

A continuación, resta las reservas para efectos adicionales de RSS y del asignador, los búferes no contabilizados para la expulsión, los picos de persistencia y un margen de seguridad. El resultado es un valor provisional maxmemory-Presupuesto, no es una ecuación interna de Redis. Las reservas deben ajustarse al mismo límite y a situaciones de carga que se produzcan simultáneamente de forma realista.

Ejemplo ilustrativo de cálculo, no es una medición: de un límite de contenedor de 8 GiB, se deducen 0,5 GiB para otros consumidores, 0,5 GiB para efectos RSS adicionales, 0,5 GiB para búferes excluidos del cálculo de expulsión, 1 GiB para un pico de persistencia y 0,5 GiB de margen de seguridad. Como valor provisional, quedan 5 GiB para maxmemory.

Estas cifras no constituyen una recomendación para una instancia concreta. El ejemplo parte de la base de que las reservas asignadas describen contribuciones adicionales y no superpuestas al límite del contenedor. Precisamente en una ejecución persistente, las páginas de memoria compartidas y el «copy-on-write» pueden dificultar la asignación; una simple suma de los valores RSS del proceso padre y del proceso hijo no sería adecuada para ello.

Evita Contabilizaciones duplicadas: mem_not_counted_for_evict ya está incluido en used_memory. Si partes del consumo total observado de RSS o del contenedor, no debes volver a sumar esta parte del búfer sin comprobarla. En el presupuesto de expulsión restante deben caber tanto el conjunto de datos como la sobrecarga de Redis que se ha tenido en cuenta; comprueba después este enfoque bajo una carga comparable.

Comparación práctica de las políticas de desahucio

El Política de desalojo Determina cómo reacciona Redis ante los comandos de escritura cuando hay escasez de memoria. No sustituye a la planificación de la capacidad: incluso una política adecuada requiere reservas al margen del cálculo de expulsión. La decisión depende, sobre todo, de qué claves se pueden perder y de cómo reacciona la aplicación ante los errores.

En el caso de una caché pura, se puede allkeys-lru son adecuadas cuando las entradas eliminadas se pueden reconstruir a partir de otra fuente. En Redis, el algoritmo LRU es una aproximación y no una ordenación global exacta. Las expulsiones frecuentes pueden provocar un mayor número de accesos al backend; por eso, no solo son importantes los bytes libres, sino también la tasa de aciertos de la caché y la capacidad del backend.

En el caso de los datos que no se pueden borrar arbitrariamente, noeviction Otra decisión: la aplicación debe poder gestionar los procesos de escritura fallidos, en lugar de dar por sentado tácitamente que el almacenamiento se ha realizado con éxito. La política no garantiza ni la persistencia ni la protección frente a un error OOM a nivel del sistema operativo o del contenedor.

En el caso de las poblaciones mixtas, la Disciplina TTL fundamental: Una volatile-*-La política solo puede seleccionar claves con un tiempo de caducidad. Si hay muy pocos candidatos adecuados, el TTL por sí solo no protege contra los errores de escritura. Por lo tanto, comprueba si la caché y los datos importantes realmente deben compartir la misma instancia y la misma estrategia de gestión de errores.

Los datos de sesión ponen de manifiesto el conflicto de objetivos: la eliminación de una entrada puede suponer para los usuarios la pérdida del estado de la sesión, aunque la aplicación siga funcionando técnicamente. Evalúa las consecuencias y la posibilidad de recuperación antes de elegir una política; el artículo sobre Gestión de sesiones con Redis y otros sistemas de almacenamiento.

Comprobar la reserva bajo carga

Un valor calculado para maxmemory Es, en primer lugar, un punto de partida. Pruébalos en un entorno aislado con una versión de Redis, una estructura de datos y un límite de memoria similares. La carga no solo debe reflejar el funcionamiento habitual, sino también los picos de escritura y las fases en las que la persistencia y la replicación están activas al mismo tiempo.

Fíjate en el Consumo de contenedores o la métrica correspondiente del host, así como los valores de memoria de Redis. Anota cuándo se está ejecutando una instantánea o una reescritura AOF y si se está sincronizando una réplica. Lo decisivo es cuánto margen queda hasta el límite real durante los eventos que se solapan, no solo en el tiempo de inactividad posterior.

Con el comando de lectura INFO stats Entre otras cosas, debes registrar los contadores de expulsiones. Analiza su evolución por intervalos de tiempo: un nivel histórico elevado por sí solo no indica si se están expulsando claves en ese momento. Relaciona el aumento de las expulsiones con las aciertos de caché y la carga del backend, siempre que tu aplicación facilite estos datos.

Además, registra las respuestas OOM de Redis en la aplicación y los incidentes de los contenedores relacionados con el almacenamiento en la plataforma. Ambos errores pueden producirse con una carga similar, pero afectan a límites distintos. Por lo tanto, una alerta debería tener en cuenta tanto la reserva disponible como los errores observados y su evolución a lo largo del tiempo.

Repite la evaluación tras realizar cambios en el conjunto de datos, en la carga de escritura o en la persistencia y la replicación. Una promoción también modifica el papel de una réplica y, por lo tanto, el perfil de carga que se debe analizar. Los resultados obtenidos en el entorno aislado no sustituyen a la supervisión continua de las instancias en producción.

Identificar de forma específica los problemas de memoria

Si el RSS del proceso aumenta mientras used_memory Si se libera memoria, ten en cuenta primero el historial y la carga previa. La memoria liberada no tiene por qué devolverse inmediatamente al sistema operativo. La Métricas del asignador de INFO memory Ayudan a interpretar los datos; el índice de fragmentación por sí solo no demuestra ni la existencia de una fuga de memoria ni su causa.

A continuación, comprueba si el aumento coincide en el tiempo con una carrera de resistencia o con una sincronización. Para ello sirven INFO persistence y INFO replication. Un valor aislado correspondiente a un búfer que no se tiene en cuenta para el desalojo solo describe el estado actual. Para calcular una reserva, necesitas observaciones que abarquen las fases relevantes de carga y de perturbación.

En el caso de una Respuesta de OOM de Redis Comprueba la política configurada y si hay claves adecuadas para una expulsión. En particular, una orden de escritura puede fallar si Redis no puede liberar espacio suficiente según la política vigente. La aplicación debe gestionar este error, en lugar de dar por sentado que la operación de escritura se ha realizado con éxito.

En cambio, en caso de una interrupción del contenedor por motivos de memoria, analiza los eventos de la plataforma y el consumo en relación con el límite del contenedor. Ten en cuenta los picos de persistencia y otros consumidores registrados en el contenedor. Un error OOM de Redis y un error OOM del contenedor no son lo mismo: el límite de memoria externo puede alcanzarse incluso sin que se haya producido previamente un error OOM de Redis.

maxmemory-clients También puede limitar la memoria ocupada por los clientes. Si la memoria del cliente en cuestión supera el umbral configurado, Redis puede desconectar a los clientes con un consumo elevado; las aplicaciones deben gestionar las interrupciones de conexión. Este ajuste no limita todas las conexiones de replicación y no sustituye ni al presupuesto total ni a la supervisión de los picos de búfer.

Valorar el alojamiento y la arquitectura de Redis

Si la reserva observada no es suficiente con una carga representativa, puede ser conveniente aumentar la RAM si se pretende que el conjunto de datos y la carga permanezcan, en principio, en una misma instancia. Sin embargo, la capacidad adicional debe formar parte del límite efectivo del host o del contenedor. Un límite de Redis mayor por sí solo no genera memoria física adicional.

Como alternativa, se puede utilizar una Distribución de la carga distribuir las necesidades de memoria y las operaciones de escritura entre varias instancias. Esto requiere una distribución adecuada de los datos y una asignación presupuestaria específica para cada instancia implicada. Las réplicas no deben equipararse a una división del conjunto de datos: básicamente, conservan una copia y, para ello, necesitan su propia memoria RAM.

También puede ser útil un cambio en la arquitectura, como la separación de una caché tolerante a pérdidas de los datos con requisitos más estrictos. De este modo, es posible seleccionar las políticas y las capacidades de forma independiente. Sin embargo, ni esta separación, ni una mayor cantidad de RAM, ni el reparto de la carga garantizan que en el futuro no se produzcan picos de persistencia, replicación y escritura.

Al comparar Límites de los proveedores Aclara si el valor indicado se refiere a un límite de contenedores, un límite de instancias o un límite de la base de datos definido de otra forma. Pregunta también qué métricas y comandos de diagnóstico están disponibles, si las réplicas están incluidas en el almacenamiento contratado y cómo afecta una promoción a los recursos disponibles.

Redis Open Source, Redis Software y Redis Cloud deben considerarse por separado. En el caso de Redis Software, se aplica el límite de base de datos documentado para los shards primarios y réplicas; de ello no se deriva ninguna regla correspondiente para una única instancia de Redis OSS. En el caso de Redis Cloud y otras ofertas de alojamiento, debes consultar las condiciones específicas de cada producto, en lugar de aplicar esta definición sin verificarla.