caching - usar - tablas en redis

¿Cómo funciona Redis cuando la RAM comienza a llenarse?

Question

Podría estar totalmente fuera, pero mi comprensión de cómo las tiendas de caché solían funcionar antes de que comenzaran a agregar características de persistencia, es que los artículos caducarían según su ttl. Y si la tienda comenzara a llenar la memoria RAM disponible, cada uno tendría sus algoritmos para caducar las claves menos "importantes" en la tienda.

Ahora leo que Redis tiene características de persistencia. Pero puedes apagarlos. Suponiendo que apaga la persistencia, ¿qué sucede cuando la memoria RAM se llena? ¿Cómo decide Redis qué expirará?

Espero tener muchos datos sin TTL y quiero asegurarme de que sea seguro dejar que Redis descubra qué expirará.

Answer 1

Didier tiene razón al indicar cómo se debe hacer esto. Simplemente indicando algunos elementos adicionales (uno de los cuales parece omitirse de su publicación):

1. Especifique el tamaño máximo de la memoria para ocupar la mayor parte de la memoria disponible en ese nodo (deje algunos para el sistema operativo y otros procesos y algunos búfers). Esto asegurará que el contenido nunca se pagine y, como tal, las operaciones son RÁPIDAS.
   1. Si no está configurando TTLs / expirando claves a través de la aplicación, entonces es importante que use el enfoque "allkeys-lru". De lo contrario, Redis no caducará nada (porque ninguna de las teclas es volátil), y comenzará a recibir errores una vez que se haya agotado toda la memoria, básicamente no podrá realizar más operaciones de conjunto.
   2. Cuando se utiliza la LRU para eliminar claves, es importante establecer la siguiente configuración:

maxmemory-samples 10

Este es el número de muestras que tomará Redis y luego eliminar la clave LRU de entre ellas. El valor predeterminado es 3 pero, para todos los fines prácticos, es demasiado bajo, y puede significar que las claves anteriores aún pueden haber sobrevivido. Establecer esto demasiado alto será una sobrecarga para Redis. Es posible que desee experimentar con esta configuración un poco antes de configurarlo. Estamos usando un valor de 10.

Answer 2

Establezca TTL (y deje que Redis maneje la caducidad) o publique sus elementos con sus propios datos de antigüedad, tal vez almacenados como un ZSET de tuplas (marca de tiempo, clave) desde las que puede realizar su propia limpieza de caché según sus propias necesidades.

Answer 3

Lea el capítulo Memoria virtual de la documentación de Redis. La parte relevante:

La configuración vm-max-memory La configuración vm-max-memory especifica la cantidad de memoria que Redis es libre de usar antes de comenzar a intercambiar valores en el disco.

Básicamente, si no se alcanza este límite de memoria, no se intercambiará ningún objeto, Redis funcionará con todos los objetos en la memoria, como de costumbre. Sin embargo, una vez que se alcanza este límite, se intercambian suficientes objetos para devolver la memoria justo por debajo del límite.

Los objetos intercambiados son principalmente los que tienen la mayor "edad" (es decir, el número de segundos desde que no se han utilizado), pero la "capacidad de intercambio" de un objeto también es proporcional al logaritmo de su tamaño en la memoria. Entonces, aunque se prefieren los objetos más antiguos, los objetos más grandes se intercambian primero cuando tienen más o menos la misma edad.

ADVERTENCIA: Debido a que las claves no se pueden intercambiar, Redis no podrá respetar la configuración de vm-max-memory si solo las teclas usan más espacio que el límite.

El mejor valor para esta configuración es suficiente RAM para contener el "conjunto de trabajo" de datos. En términos prácticos, solo da a Redis tanta memoria como puedas, y el intercambio funcionará mejor.

ACTUALIZACIÓN En cuanto a Redis 2.4 (parece que la documentación oficial en el sitio de Redis no se actualiza a esa versión), no se recomienda el uso de VM.

redis.conf dice:

### WARNING! Virtual Memory is deprecated in Redis 2.4
### The use of Virtual Memory is strongly discouraged.

Answer 4

No creo que la pregunta esté relacionada con la administración de la memoria virtual, sino más sobre la caducidad de los elementos en Redis, que es un tema totalmente diferente.

Al contrario de memcached, Redis no es solo un caché. Por lo tanto, se supone que el usuario debe elegir la política de desalojo del artículo utilizando varios mecanismos. Puede desalojar todos sus artículos, o solo una parte de ellos.

La política general debe seleccionarse en el archivo de configuración con los parámetros maxmemory y maxmemory-policy, descritos a continuación:

# Don''t use more memory than the specified amount of bytes.
# When the memory limit is reached Redis will try to remove keys with an
# EXPIRE set. It will try to start freeing keys that are going to expire
# in little time and preserve keys with a longer time to live.
# Redis will also try to remove objects from free lists if possible.
#
# If all this fails, Redis will start to reply with errors to commands
# that will use more memory, like SET, LPUSH, and so on, and will continue
# to reply to most read-only commands like GET.
#
# WARNING: maxmemory can be a good idea mainly if you want to use Redis as a
# ''state'' server or cache, not as a real DB. When Redis is used as a real
# database the memory usage will grow over the weeks, it will be obvious if
# it is going to use too much memory in the long run, and you''ll have the time
# to upgrade. With maxmemory after the limit is reached you''ll start to get
# errors for write operations, and this may even lead to DB inconsistency.
#
maxmemory <bytes>
# MAXMEMORY POLICY: how Redis will select what to remove when maxmemory
# is reached? You can select among five behavior:
#
# volatile-lru -> remove the key with an expire set using an LRU algorithm
# allkeys-lru -> remove any key accordingly to the LRU algorithm
# volatile-random -> remove a random key with an expire set
# allkeys->random -> remove a random key, any key
# volatile-ttl -> remove the key with the nearest expire time (minor TTL)
# noeviction -> don''t expire at all, just return an error on write operations
#
# Note: with all the kind of policies, Redis will return an error on write
# operations, when there are not suitable keys for eviction.
#
# At the date of writing this commands are: set setnx setex append
# incr decr rpush lpush rpushx lpushx linsert lset rpoplpush sadd
# sinter sinterstore sunion sunionstore sdiff sdiffstore zadd zincrby
# zunionstore zinterstore hset hsetnx hmset hincrby incrby decrby
# getset mset msetnx exec sort
#
# The default is:
#
maxmemory-policy volatile-lru
# LRU and minimal TTL algorithms are not precise algorithms but approximated
# algorithms (in order to save memory), so you can select as well the sample
# size to check. For instance for default Redis will check three keys and
# pick the one that was used less recently, you can change the sample size
# using the following configuration directive.
#
maxmemory-samples 3

A continuación, la caducidad del elemento individual se puede configurar con los siguientes comandos: EXPIREAT La propiedad de caducidad por elemento es útil con las políticas volátiles- *. La caducidad también puede eliminarse utilizando PERSIST .

La propiedad de caducidad agrega una ligera sobrecarga de memoria, por lo que debe usarse solo si es necesario.

Finalmente, vale la pena mencionar que una parte de un objeto no puede expirar, solo el objeto completo en sí mismo. Por ejemplo, una lista completa o conjunto correspondiente a una clave puede expirar, pero la lista individual o los elementos configurados no pueden.