Redis hafızası bittiğinde ne yapar?


111

Bu kolay bir soru olabilir ama cevabını bulmakta zorlanıyorum. Redis 2.0, ayrılan maksimum belleğin azalmasını nasıl ele alıyor? Hangi verilerin silineceğine veya hangi verilerin bellekte tutulacağına nasıl karar verir?


Yanıtlar:


94

Sanal bellek işlevselliği açıksa (sürüm 2.0 veya 2.2'de yeni olduğunu düşünüyorum), bellek bittiğinde Redis "çok sık kullanılmayan" verileri diske depolamaya başlar.

Redis'teki sanal bellek devre dışı bırakılırsa, işletim sisteminin sanal belleği tükenmeye (yani takas) başlar ve performans muazzam bir şekilde düşer gibi görünür.

Artık Redis'i, Redis'in daha fazla bellek (varsayılan) kullanmasını engelleyen bir maxmemory parametresiyle de yapılandırabilirsiniz.

Redis'in daha yeni sürümleri, maxmemory'ye ulaşıldığında çeşitli politikalara sahiptir:

  • volatile-lru, son zamanlarda kullanılmayan anahtarları çıkarmaya çalışarak, süresi dolmuş olanlardan bir anahtarı kaldırır.
  • volatile-ttl, süresi dolmuş olanlardan bir anahtarı kaldırarak, kalan ömrü kısa olan anahtarları çıkarmaya çalışır.
  • uçucu-rasgele, süresi dolmuş olanlardan rastgele bir anahtarı kaldırır.
  • allkeys-lru volatile-lru gibidir, ancak her türlü anahtarı, hem normal anahtarları hem de süresi dolan anahtarları kaldırır.
  • allkeys-rasgele uçucu-rasgele gibi, ancak her tür anahtarı, hem normal anahtarları hem de süresi dolan anahtarları kaldırır.

Yalnızca EXPIRE kümesiyle anahtarları kaldıran bir politika seçerseniz, Redis'in belleği bittiğinde, program malloc () işlemini iptal etmiş gibi görünür. Yani, daha fazla veri depolamaya çalışırsanız, işlem sefil bir şekilde başarısız olur.

Daha fazla bilgi için bazı bağlantılar (çünkü sadece benim sözüme güvenmemelisiniz):


8
Redis Sanal Belleği artık kullanımdan kaldırılmıştır. Bkz redis.io/topics/virtual-memory
cgaldiolo

19

Gönderen redis.conf , sürüm 2.8

# Don't use more memory than the specified amount of bytes.
# When the memory limit is reached Redis will try to remove keys
# according to the eviction policy selected (see maxmemory-policy).
#
# If Redis can't remove keys according to the policy, or if the policy is
# set to 'noeviction', Redis will start to reply with errors to commands
# that would use more memory, like SET, LPUSH, and so on, and will continue
# to reply to read-only commands like GET.
#
# This option is usually useful when using Redis as an LRU cache, or to set
# a hard memory limit for an instance (using the 'noeviction' policy).
#
# WARNING: If you have slaves attached to an instance with maxmemory on,
# the size of the output buffers needed to feed the slaves are subtracted
# from the used memory count, so that network problems / resyncs will
# not trigger a loop where keys are evicted, and in turn the output
# buffer of slaves is full with DELs of keys evicted triggering the deletion
# of more keys, and so forth until the database is completely emptied.
#
# In short... if you have slaves attached it is suggested that you set a lower
# limit for maxmemory so that there is some free RAM on the system for slave
# output buffers (but this is not needed if the policy is 'noeviction').
#
# maxmemory <bytes>

# MAXMEMORY POLICY: how Redis will select what to remove when maxmemory
# is reached. You can select among five behaviors:
#
# volatile-lru -> remove the key with an expire set using an LRU algorithm
# allkeys-lru -> remove any key according 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 any of the above policies, Redis will return an error on write
#       operations, when there are no suitable keys for eviction.
#
#       At the date of writing these 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

3
maxmemory-policyRedis 3.2'de varsayılan şimdi noeviction: raw.githubusercontent.com/antirez/redis/3.2/redis.conf
LoicAG

5

Redis 4.0'ı güncelleyin

127.0.0.1:6379> MEMORY HELP
1) "MEMORY DOCTOR                        - Outputs memory problems report"
2) "MEMORY USAGE <key> [SAMPLES <count>] - Estimate memory usage of key"
3) "MEMORY STATS                         - Show memory usage details"
4) "MEMORY PURGE                         - Ask the allocator to release memory"
5) "MEMORY MALLOC-STATS                  - Show allocator internal stats"

/usr/local/etc/redis.conf

############################## MEMORY MANAGEMENT ################################

# Set a memory usage limit to the specified amount of bytes.
# When the memory limit is reached Redis will try to remove keys
# according to the eviction policy selected (see maxmemory-policy).
#
# If Redis can't remove keys according to the policy, or if the policy is
# set to 'noeviction', Redis will start to reply with errors to commands
# that would use more memory, like SET, LPUSH, and so on, and will continue
# to reply to read-only commands like GET.
#
# This option is usually useful when using Redis as an LRU or LFU cache, or to
# set a hard memory limit for an instance (using the 'noeviction' policy).
#
# WARNING: If you have slaves attached to an instance with maxmemory on,
# the size of the output buffers needed to feed the slaves are subtracted
# from the used memory count, so that network problems / resyncs will
# not trigger a loop where keys are evicted, and in turn the output
# buffer of slaves is full with DELs of keys evicted triggering the deletion
# of more keys, and so forth until the database is completely emptied.
#
# In short... if you have slaves attached it is suggested that you set a lower
# limit for maxmemory so that there is some free RAM on the system for slave
# output buffers (but this is not needed if the policy is 'noeviction').
#
# maxmemory <bytes>

# MAXMEMORY POLICY: how Redis will select what to remove when maxmemory
# is reached. You can select among five behaviors:
#
# volatile-lru -> Evict using approximated LRU among the keys with an expire set.
# allkeys-lru -> Evict any key using approximated LRU.
# volatile-lfu -> Evict using approximated LFU among the keys with an expire set.
# allkeys-lfu -> Evict any key using approximated LFU.
# volatile-random -> Remove a random key among the ones 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 evict anything, just return an error on write operations.
#
# LRU means Least Recently Used
# LFU means Least Frequently Used
#
# Both LRU, LFU and volatile-ttl are implemented using approximated
# randomized algorithms.
#
# Note: with any of the above policies, Redis will return an error on write
#       operations, when there are no suitable keys for eviction.
#
#       At the date of writing these 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 noeviction

# LRU, LFU and minimal TTL algorithms are not precise algorithms but approximated
# algorithms (in order to save memory), so you can tune it for speed or
# accuracy. For default Redis will check five keys and pick the one that was
# used less recently, you can change the sample size using the following
# configuration directive.
#
# The default of 5 produces good enough results. 10 Approximates very closely
# true LRU but costs more CPU. 3 is faster but not very accurate.
#
# maxmemory-samples 5

4

Yakın zamanda Redis hakkında okumaya başladım, bu yüzden pozitif değilim. Ancak yararlı olabilecek birkaç haberle karşılaştım.

Http://antirez.com/post/redis-as-LRU-cache.html adresinden bir pasajı burada bulabilirsiniz :

Redis'i önbellek olarak kullanmanın başka bir yolu, kullanılacak maksimum bellek miktarını belirlemeye izin veren bir özellik olan maxmemory direktifidir. Sunucuya yeni veri eklendiğinde ve bellek sınırına zaten ulaşıldığında, sunucu, anahtar hala uzakta olsa bile, geçici bir anahtarı, yani EXPIRE (zaman aşımı) ayarlı bir anahtarı silerek bazı eski verileri kaldıracaktır. otomatik olarak sona ermekten.

Ayrıca Redis 2.0, tüm anahtarların belleğe sığması gereken bir VM moduna sahiptir, ancak nadiren kullanılan anahtarların değerleri diskte olabilir:


2

Redis (2.8) 'in yapılandırmasıyla tanımlanan maksimum değere ulaştığında gerçekte ne tepki verdiğini merak ediyorsanız, şöyle görünür:

$ redis-cli
127.0.0.1:6379> GET 5
"bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb"
127.0.0.1:6379> SET 5 a
(error) OOM command not allowed when used memory > 'maxmemory'.

1

Kısa bir süre önce boş belleksiz bir durum yaşadım ve uygulamam durma noktasına geldi (yazma mümkün değil, okumalar mümkündü), PHP betiklerini çalıştırma yollarının ortasında tamamen durdu ve kill -9manuel olarak 'd hazır).

Veri kaybı (veya veri tutarsızlığı) olduğunu varsayarak bir flushdbyedekleme yaptım ve yedeklemelerden geri yükledim. Ders öğrenildi? Yedeklemeler sizin dostunuzdur.


-3

Redis, memcached gibi bir önbellek değildir, varsayılan olarak (burada maxmemory-policyparametrenin ayarlandığı yerlerde noeviction) redis'e koyduğunuz tüm veriler kaldırılmaz, tek istisna EXPIRE kullanmaktır.


2
Peki hafızası tükendiğinde ne yapar? Yeni verileri bellekte değil diskte mi depolayacak?
Cory

1
Bu (şimdi) yanlıştır, Redis birkaç mevcut politikayla birlikte önemli bir tahliye mekanizmasına sahiptir: redis.io/topics/lru-cache
LoicAG

@LoicAG: Bana tamamen doğru geliyor ... bir açıklama politikası olmadığı sürece, Redis herhangi bir anahtarı çıkarmaz. Ve bu iyi: Örneğin Redis'in kendi başına anahtarlardan kurtulmasını göze alamam.
Michael

@Cory: Bir tahliye politikası ayarlanmışsa, mevcut anahtarları kaldırır. Ancak, herhangi bir tahliye politikası belirlemediyseniz, bellek yetersiz hatası almalısınız.
Michael

@Michael Sanırım bu bir terminoloji meselesi: her zaman bir maxmemory politikası vardır ve varsayılan gerçekten "noeviction" dır; ancak "allkeys-lru" ve "allkeys-random" ilkeleri, anahtarları tüm kümeden çıkarır ve diğer ("uçucu- *"), TTL tanımlı anahtarların alt kümesinden anahtarları çıkarır.
LoicAG
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.