如何在Redis中监控已缓存Lua脚本的内存占用？-Redis-PHP中文网

redis无法直接查看lua脚本内存占用，其缓存不计入used_memory统计；真正影响内存的是执行时的临时对象，需通过慢日志、命令统计和客户端日志等间接方式监控脚本行为。

如何在redis中监控已缓存lua脚本的内存占用？

Redis不提供直接查看Lua脚本内存占用的命令

你无法通过 INFO memory 或 MEMORY USAGE 查到某个 Lua 脚本本身占了多少内存。Redis 把已加载的脚本缓存在内部结构（server.lua_scripts 字典）里，但这些对象不暴露为可查 key，也不计入 used_memory 的常规统计项——它们的内存开销被归入“元数据开销”或“其他内部结构”，混在 used_memory 里无法剥离。

实际影响更大的是脚本执行时的临时内存：比如 table.new(10000, 0)、拼接大字符串、或 redis.call("SMEMBERS", "huge-set") 返回几 MB 数据后在 Lua 里遍历——这部分会真实推高 RSS，但属于运行时堆栈，脚本结束后即释放，无法用静态方式监控。

间接判断脚本缓存是否成为内存负担

虽然看不到单个脚本大小，但可以观察整体缓存行为是否异常：

Redis 8.2.3

Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。

下载

SCRIPT LOAD 每次调用都会把脚本文本完整存进内存，重复加载同一逻辑（尤其没做 SHA 校验去重）会导致冗余副本
用 SCRIPT EXISTS 批量检查已加载脚本数量：SCRIPT EXISTS script1 script2 ... script100，若返回大量 1，且总数持续增长，说明客户端未复用 EVALSHA
对比 INFO commandstats 中 cmdstat_script_load 的调用频次和 cmdstat_evalsha ——如果前者占比 >5%，基本意味着脚本管理失控
注意 used_memory_peak 是否在批量上线新服务后明显跳升，再结合部署时间点反查是否集中 SCRIPT LOAD 了大量长脚本

真正该监控的是脚本执行行为，而非脚本本身

脚本缓存内存本身通常很小（几百字节/个），危险来自执行过程。重点盯住这些信号：

慢日志里出现 EVAL 或 EVALSHA 耗时接近 lua-time-limit（默认 5000ms），说明脚本正在霸占单线程
INFO stats 中的 total_commands_processed 突降 + rejected_connections 上升，可能是脚本超时触发 busy 状态，阻塞新连接
redis.call() 调用次数超过 5 次的脚本，实测延迟增幅超 40%，应拆分或改用原生命令组合
脚本里用了 KEYS、HGETALL、SMEMBERS 且没加 COUNT 限制，极易在数据增长后突然爆内存

想定位具体哪个脚本有问题？靠日志+客户端配合

Redis 服务端不记录脚本内容，只能靠外部手段关联：

启用慢日志：CONFIG SET slowlog-log-slower-than 10000（单位微秒），确保捕获 >10ms 的 EVALSHA
在客户端调用 EVALSHA 前，统一打日志：例如 "EVALSHA 2e8b4a9d7f (v2.1.0 stock_deduct) with keys [order:123]"，把 SHA 和业务语义绑定
用 SCRIPT DEBUG YES 开启调试模式（仅限开发环境！），此时 redis-cli monitor 会显示脚本内每行执行耗时，但生产禁用
定期导出所有已加载脚本：SCRIPT FLUSH 前先用 SCRIPT KILL（只对只读有效）+ 客户端缓存 SHA 列表，再通过 SCRIPT LOAD 重建，过程中记录每个脚本长度（string.len(script_text)）