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确认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

这听起来像操作系统的工作＆＃39; OOM杀手 - 您可以通过查看/var/log/syslog验证/诋毁该假设。

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

请注意free事后并非有用 - 您需要持续监控资源。

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

诊断意外的redis-server故障

1 个答案: