如何调试Redis中的错误“OOM command not allowed when used memory > 'maxmemory'”?

yizd12fk  于 2023-06-28  发布在  Redis
关注(0)|答案(7)|浏览(261)

我得到“OOM命令不允许”当试图设置一个键,maxmemory被设置为500 M与maxmemory-policy“volatile-lru”,我设置TTL为每个键发送到redis.
INFO命令返回:used_memory_human:809.22M
1.如果maxmemory设置为500 M,我是如何达到809 M的?

  1. INFO命令不显示任何Keyspace,这是怎么可能的呢?
  2. KEYS *返回“(empty list or set)”,我已经尝试更改数据库号,仍然没有找到键。
    下面是info命令输出:
redis-cli -p 6380
redis 127.0.0.1:6380> info
# Server
redis_version:2.6.4
redis_git_sha1:00000000
redis_git_dirty:0
redis_mode:standalone
os:Linux 2.6.32-358.14.1.el6.x86_64 x86_64
arch_bits:64
multiplexing_api:epoll
gcc_version:4.4.7
process_id:28291
run_id:229a2ee688bdbf677eaed24620102e7060725350
tcp_port:6380
uptime_in_seconds:1492488
uptime_in_days:17
lru_clock:1429357

# Clients
connected_clients:1
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0

# Memory
used_memory:848529904
used_memory_human:809.22M
used_memory_rss:863551488
used_memory_peak:848529192
used_memory_peak_human:809.22M
used_memory_lua:31744
mem_fragmentation_ratio:1.02
mem_allocator:jemalloc-3.0.0

# Persistence
loading:0
rdb_changes_since_last_save:0
rdb_bgsave_in_progress:0
rdb_last_save_time:1375949883
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:-1
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

# Stats
total_connections_received:3
total_commands_processed:8
instantaneous_ops_per_sec:0
rejected_connections:0
expired_keys:0
evicted_keys:0
keyspace_hits:0
keyspace_misses:0
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:0

# Replication
role:master
connected_slaves:0

# CPU
used_cpu_sys:18577.25
used_cpu_user:1376055.38
used_cpu_sys_children:0.00
used_cpu_user_children:0.00

# Keyspace
redis 127.0.0.1:6380>
qyyhg6bp

qyyhg6bp1#

Redis的maxmemory volatile-lru策略可能无法释放足够的内存,如果maxmemory限制已经被非volatile键使用。

x7yiwoj4

x7yiwoj42#

你有没有可能改变了数据库的数量如果使用非常大的数字,那么初始内存使用量可能会很高

gojuced7

gojuced73#

在我们的例子中,maxmemory被设置为一个很高的值,然后团队中的某个人在数据已经存储之后将其更改为一个较低的值。

gt0wga4j

gt0wga4j4#

我的问题是旧数据没有被释放,这导致redis数据库很快就堵塞了。在Python中,我通过运行以下命令清除该高速缓存服务器

red = redis.StrictRedis(...)
red.flushdb()

然后,通过使用“ex”保存文件将ttl限制为24h:

red.set(<FILENAME>, png, ex=(60*60*24))
50pmv0ei

50pmv0ei5#

内存在配置中控制。因此,你的例子有限,因为它说。您可以查看redis.conf或从CLI工具发出“configgetmaxmemory”来获取限制。
如果你管理这个Redis示例,你需要查看并调整配置文件。通常在/etc/redis.conf或/etc/redis/redis. conf中查找。
如果你使用的是Redis提供商,你需要和他们商量一下增加你的限制。

5m1hhzi4

5m1hhzi46#

要调试此问题,需要检查您在redis-cli上手动或从代码某处执行的操作。
1.可能您运行了keys *,并且只有很少的内存来容纳此命令所消耗的内存。这会导致对缓存服务进行节流。
1.在代码中,您的更改可能会影响数据库中的键插入和重复或唯一数据,这会导致系统中的总内存超出。

px9o7tmv

px9o7tmv7#

验证Redis示例的内存使用情况

你可以通过运行下面的命令来了解你的Hypernode上的Redis内存。

redis-cli info | grep memory_human

# Memory
used_memory_human:331.51M
total_system_memory_human:5.83G
maxmemory_human:896.00M

修复

快速解决方法是刷新Redis缓存,这样就有足够的Redis内存可用了。你可以通过跑步

redis-cli flushall

为了防止这种情况,你可以尝试对Redis数据进行压缩,但大多数情况下,这只能暂时阻止问题。一段时间后,当Redis缓存再次完全填满时,错误将再次出现。

检查您的密钥是否设置了过期

您可以使用下面的命令检查密钥

redis-cli info keyspace

# Keyspace
db0:keys=59253,expires=1117,avg_ttl=81268890
db1:keys=13608,expires=904,avg_ttl=82515590
db2:keys=144,expires=144,avg_ttl=199414742

这将给予你一些关于你配置的Redis数据库、密钥以及它们是否有过期的见解。在上面的例子中,大量的Redis密钥没有过期设置。这意味着这些密钥永远不会过期,也不会从Redis缓存中删除,为新密钥腾出位置。结果该高速缓存将处于达到其最大值的更大风险。
然而,要解决这个问题,只有一个真实的的解决方案:升级到内存更大的节点。
here is the guide

相关问题