redis崩溃时默认不生成coredump，是因为linux内核默认将进程core文件大小限制为0，redis继承该限制；启用需同时配置ulimit -c unlimited和/proc/sys/kernel/core_pattern，并确保路径可写。
Redis崩溃时为什么默认不生成coredump
Linux内核默认限制进程的core文件大小为0，Redis启动后继承该限制，即使崩溃也不会落盘coredump。这不是Redis的问题，而是系统级防护机制。检查当前限制用 ulimit -c，多数生产环境返回 0。
启用coredump需同时改系统和Redis配置
只改Redis配置没用，必须两步都做：
- 在Redis启动前，用
ulimit -c unlimited临时放开限制（推荐写入Redis服务的systemd Unit文件或启动脚本中） - 确保
/proc/sys/kernel/core_pattern指向可写的路径，比如/var/core/core.%e.%p.%t，且目录存在、权限正确 - Redis自身无需额外配置项——它不控制core生成，只依赖系统行为
RDB和coredump是两套完全独立的机制
别混淆二者：RDB 是Redis主动快照内存数据（靠 save 或 BGSAVE），而 coredump 是内核在进程异常终止（如段错误、SIGABRT）时强制 dump 整个进程地址空间。它们触发条件、生成时机、文件内容、用途全都不一样。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- RDB文件（如
dump.rdb）可被Redis重启时加载，用于业务数据恢复 - core文件（如
core.redis.12345.1725485220）需用gdb redis core.xxx分析崩溃现场，定位bug或内存破坏 - 若Redis因OOM被kill，通常不会生成core（取决于
/proc/sys/kernel/core_pattern是否启用pipe模式及对应handler是否存活）
生产环境要特别注意fork与coredump的资源竞争
大内存Redis实例在频繁 BGSAVE 时，fork() 本身就会消耗大量内存页表资源；如果此时又发生崩溃并尝试生成GB级core文件，可能直接触发磁盘IO打满或空间耗尽。建议：
- 将core文件路径挂载到独立高速盘（如NVMe），避免和RDB目录共用同一文件系统
- 用
coredumpctl或systemd-coredump管理core生命周期，自动压缩/过期清理 - 不要在
redis.conf中盲目增加save频率来“弥补”崩溃风险——RDB无法替代core分析价值
真正容易被忽略的是：coredump能否生成，90%取决于系统配置是否生效，而不是Redis配了什么；而RDB能否及时落地，关键在 stop-writes-on-bgsave-error yes 这类兜底开关是否开着。
