诊断意外的redis-server故障

Question

今天，我的一台redis服务器一再故障，没有任何公开的、可诊断的原因。我的用户最终都会收到Error 111 connecting to unix socket: /var/run/redis/redis2.sock. Connection refused错误。

查看/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确认交换被设置为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

这听起来像是OS‘OOM杀手的工作--您可以通过查看/var/log/syslog来验证/诋毁假设。

在这种情况下，持久性作业的开销触发了杀手。为此，您需要设置maxmemory并分配足够的内存来满足持久性的需求，包括COW。

注意，free在这一事实之后并不有用--您需要持续监视您的资源。

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