小编典典

诊断意外的Redis服务器故障

redis

我的一台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

阅读 386

收藏
2020-06-20

共1个答案

小编典典

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

在这种情况下,持久性作业的开销触发了杀手er。您需要通过设置maxmemory和分配足够的RAM来满足持久性的需求(包括COW)来进行配置。

请注意,free事实并非如此-您需要连续监视资源。

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

2020-06-20