redis - 诊断意外的 redis 服务器故障

Question

我的一个 redis 服务器今天反复宕机，没有任何明显的、可诊断的原因。我的用户最终都收到 错误 111 连接到 unix 套接字:/var/run/redis/redis2.sock。连接被拒绝 错误。

查看 /var/log/redis 中的日志，最后几行捕捉到的不过是计划的备份而已:

[8248] 09 Mar 07:48:17.090 * 10 changes in 21600 seconds. Saving...
[8248] 09 Mar 07:48:17.374 * Background saving started by pid 47613
[47613] 09 Mar 07:51:02.257 * DB saved on disk
[47613] 09 Mar 07:51:02.486 * RDB: 526 MB of memory used by copy-on-write
[8248] 09 Mar 07:51:02.920 * Background saving terminated with success

pid 文件仍然存在。这意味着服务器没有正式关闭，redis 仍然是守护进程？

我登录到我的系统并执行了两次 sudo service redis-server restart 以启动并运行它。除了这些日志，我还能如何诊断可能出了什么问题？

---

更新:我注意到在第一次崩溃时，磁盘交换开始发生。这以前没有发生过。此外，cat/proc/sys/vm/swappiness 确认 swappiness 设置为 2。

free -m 显示(正常运行后):

             total       used       free     shared    buffers     cached
Mem:         28136      27015       1120        305         80       6586
-/+ buffers/cache:      20349       7787
Swap:         1023        991         32

free -m 显示(redis 服务器宕机后):

             total       used       free     shared    buffers     cached
Mem:         28136       8770      19365        305         60        441
-/+ buffers/cache:       8268      19868
Swap:         1023       1022          1

Answer 1

这听起来像是操作系统的 OOM killer 的工作 - 您可以通过查看 /var/log/syslog 来验证/否定该假设。

在这种情况下，持久性作业的开销触发了 killer 。您需要通过设置 maxmemory 并分配足够的 RAM 来满足持久性要求(包括 COW)来为此做好准备。

请注意，free 在事后没有用 - 您需要持续监控您的资源。

至于交换，如果您不关心延迟，那么您当然可以这样做。