redis-server --test-memory 怎么判断内存测试结果

redis-server --test-memory 是 Redis 自带的快速内存检查入口，适合在 Redis 出现异常崩溃、怀疑主机内存不稳定时做第一轮判断。最重要的结论是：看到 PASSED 只能说明这次快速测试没有发现错误，不能证明内存经过长时间运行一定可靠；如果测试报错、崩溃或无法完成，应把它当成主机层面的高优先级信号。

官方文档：https://redis.io/docs/latest/operate/oss_and_stack/management/troubleshooting/

先看命令：它测的是内存，不是 Redis 数据

最小用法是给出要测试的内存容量，单位按命令行参数理解为 MB。下面的命令只表达测试意图，不会读取某个业务 key，也不等价于设置 Redis 的 maxmemory。

# 先确认当前命令来自预期的 Redis 安装
command -v redis-server

# 用 128 MB 做一次快速内存检查，数值按维护窗口调整
redis-server --test-memory 128

执行时应选择不影响业务的维护窗口，并记录二进制来源、主机、参数和完整输出。不要把正在承载流量的 Redis 实例当成普通服务继续运行；这条参数走的是测试路径，文章关注的是结果解释，不是业务数据读写。

PASSED 该怎么看

常见的通过输出会包含类似 Fast memory test PASSED 的结论。它表示本次快速内存测试完成，并且测试阶段没有报告已检测到的内存错误。这里的关键词是“快速”：Redis 官方排障文档把它描述为较快且相当可靠的内置检查，同时建议条件允许时重启主机，使用持续数小时的 MemTest86 一类工具继续检查。

因此可以按下面的方式解释：

• PASSED：本次快速检查暂未发现错误，可以继续收集 Redis 崩溃日志、操作系统日志和版本信息，但不能直接排除偶发硬件故障。
• 出现 MEMORY ERROR 或异常终止：先停止把问题归因于 Redis 业务代码，保留输出并安排主机内存、插槽和系统层面的进一步诊断。
• 命令找不到或参数不被识别：先确认使用的二进制和版本，再查对应发行版或构建产物的帮助信息，不要把“没有执行测试”误写成“测试通过”。

失败或异常结束时怎么处理

如果输出明确提示内存错误，或者进程在测试中崩溃、被信号终止、长时间没有完成，都不应继续用一次“重跑成功”覆盖原始证据。建议保留第一次完整输出，记录测试容量和主机时间，再按这个顺序处理：

1. 把该主机标记为待诊断，避免继续承载新的关键写入或把故障扩大到其他节点。
2. 检查操作系统的内存、机器检查异常和硬件日志；如果是虚拟机，还要同步检查宿主机或云平台的硬件告警。
3. 在可维护窗口安排更长时间的专用内存测试，必要时由硬件团队隔离内存条或插槽。
4. 硬件侧没有异常后，再回到 Redis 版本、模块、持久化和数据集等软件线索。

这条命令适合回答“主机内存是否值得优先怀疑”，不适合回答“Redis 能承受多少 QPS”“RDB/AOF 是否完整”或“业务请求是否正确”。这些问题分别需要压测、持久化检查和应用级验证。

把一次结果放进完整排障记录

一份可复用的记录至少包括：redis-server --version 的版本、实际二进制路径、--test-memory 的容量、完整 stdout/stderr、退出时刻，以及同一时间段的系统日志。这样即使结果是 PASSED，也能和后续崩溃报告对齐，而不是只留下一个模糊的“内存测过了”。

# 保存版本和路径，便于复盘实际使用的构建产物
redis-server --version
command -v redis-server

# 运行快速检查；输出应原样保存到排障记录
redis-server --test-memory 128 2>&1 | tee redis-test-memory.log

最后的判断可以压缩成一句话：PASSED 是快速检查的通过信号，不是硬件长期稳定性承诺；失败或异常结束则应升级为主机内存和硬件诊断任务。

常见追问

测试通过后还需要跑 MemTest86 吗？

如果问题是偶发崩溃、数据异常或主机稳定性，而不是一次明显的配置错误，建议继续安排更长时间的专用内存测试。快速测试通过不能覆盖所有长时间运行和不同温度、负载条件下的故障。

--test-memory 能替代 Redis 压测吗？

不能。它关注内存检查；压测关注吞吐、延迟、并发和数据访问模式，两者的输入、输出和结论完全不同。