我的一台Redis服务器今天反复停机,没有任何明显的可诊断原因。我所有的用户最终都会遇到Error 111 connecting to unix socket: /var/run/redis/redis2.sock. Connection refused错误。
Error 111 connecting to unix socket: /var/run/redis/redis2.sock. Connection refused
查看处的日志/var/log/redis,最后几行捕获的内容比计划的备份更为有害:
/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两次以使其启动并运行。除了这些日志,我还能如何诊断可能出了什么问题?
sudo service redis-server restart
更新:我注意到在第一次崩溃时,磁盘交换开始发生。这从未发生过。此外,cat /proc/sys/vm/swappiness确认将可交换性设置为2。
cat /proc/sys/vm/swappiness
2
free -m 显示(正常操作后):
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
这听起来像是OS的OOM杀手的工作-您可以通过查看来验证/否认该假设/var/log/syslog。
/var/log/syslog
在这种情况下,持久性作业的开销触发了杀手er。您需要通过设置maxmemory和分配足够的RAM来满足持久性的需求(包括COW)来进行配置。
maxmemory
请注意,free事实并非如此-您需要连续监视资源。
free
至于交换,如果您不关心延迟,那么您当然可以这样做。