诊断意外的Redis服务器故障

  • Z时代
  • 2024-01-10
  • 分类：问答

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

回答：

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

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

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

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

以上是 诊断意外的Redis服务器故障 的全部内容， 来源链接： utcz.com/qa/397453.html

回到顶部