Redis持续占用大量内存并不断增长，直到被OOM杀死

目前，我的8GB RAM服务器在Redis上使用了5.33GB（服务器的其他部分大约使用1.6GB，因此即使在重新启动服务器后，我的内存也已经达到了~7GB[88%]）。Redis的内存使用一直在增长，直到它最终被Ubuntu的OOM杀死，导致我的节点应用程序出现一系列错误

我在这篇文章的底部附上了Redis信息输出。我原本以为redis中的键可能太多了，但我从redis（）读到一百万个键大约是100MB。我们有大约200万（约2亿兆，远不及5GB），所以这不可能是问题所在

我的问题是： -redis在哪里消耗所有这些内存？键空间一点也不占用。 -我能做些什么来阻止它持续消耗更多内存

谢谢

# Server
redis_version:2.8.6
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:f73a208b84b18824
redis_mode:standalone
os:Linux 3.2.0-55-virtual x86_64
arch_bits:64
multiplexing_api:epoll
gcc_version:4.6.3
process_id:1286
run_id:6d3daee5341a549dfaca63706c40c44086198317
tcp_port:6379
uptime_in_seconds:1390
uptime_in_days:0
hz:10
lru_clock:771223
config_file:/etc/redis/redis.conf

# Clients
connected_clients:198
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:72

# Memory
used_memory:5720230408
used_memory_human:5.33G
used_memory_rss:5826732032
used_memory_peak:5732485800
used_memory_peak_human:5.34G
used_memory_lua:33792
mem_fragmentation_ratio:1.02
mem_allocator:jemalloc-3.5.0

# Persistence
loading:0
rdb_changes_since_last_save:94
rdb_bgsave_in_progress:0
rdb_last_save_time:1412804004
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:40
rdb_current_bgsave_time_sec:-1
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok

# Stats
total_connections_received:382
total_commands_processed:36936
instantaneous_ops_per_sec:0
rejected_connections:0
sync_full:0
sync_partial_ok:0
sync_partial_err:0
expired_keys:0
evicted_keys:0
keyspace_hits:2421
keyspace_misses:1
pubsub_channels:1
pubsub_patterns:9
latest_fork_usec:1361869

# Replication
role:master
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

# CPU
used_cpu_sys:15.95
used_cpu_user:101.34
used_cpu_sys_children:12.55
used_cpu_user_children:146.17

# Keyspace
db0:keys=2082234,expires=1162351,avg_ttl=306635722644

---

谢谢你的回复。我有一种错误的（而且真的认为不够）印象，认为键和值的大小大致相同。事实证明，kue存储了一些散列，每个散列超过10KB，我们有数十万个散列。除掉那些家伙很有效

---

再次感谢。

通过设置maxmemory避免oom杀手。你的钥匙里有什么？键的数量当然是一个因素，但它们的值的大小（以及名称的长度）也是一个因素/