什么可能导致Redis RDB快照失速？

Question

我在Ubuntu 14.04上安装了redis，而且我似乎几乎每周都有完成RDB快照的问题。 Redis版本是3.0.4 64位。

  

3838：M 24 Feb 09：46：28.826 *背景保存终止成功
  3838：M 24 Feb 09：47：29.088 * 100000在60秒内变化。保存...
  3838：M 24 Feb 09:47:29.230 *背景保存由pid开始17281
17281：signal-handler（1456338079）收到SIGTERM调度关闭...
  3838：M 24 Feb 13：24：19.358＃背景保存由信号9终止   3838：M 24 Feb 13：24：19.622 * 10在900秒内变化。保存...
  3838：M 24 Feb 13：24：19.730 *背景保存由pid 17477开始

你看到的是在上午9:47开始的背景保存，但是当我在下午1点24分找到它时，它似乎完全停滞了。我发现forked进程基本上没有活动 - 它消耗的内存量没有增加。我试图“杀死”子进程，但它实际上从未退出，所以我不得不以极端的偏见（-9）杀死它。

当事情变得糟糕时，我的应用中出现以下错误：

  

2016-02-24 13：11：12,046 [2344]错误kCollectors.Main - 添加到Redis时出错：没有可用于此操作的连接：SADD ALLCH

我的redis配置仅用于执行rdb快照（无AOF）。负载修改很重，每秒写入数千次。

目前我还没有redis后台保存成功，后台进程变得比我的VM开始交换的常规进程大得多。这是我的TOP。 3838是我的redis实例，17477是后台保存过程（如上所述）：

  

top - 14:06:42 up 118 days，2：05,1位用户，平均负载：1.07,1.07,1.13左右   任务：总共81次，3次跑步，78次睡眠，0次停止，0次僵尸
  ％Cpu（s）：0.8 us，1.5 sy，0.0 ni，45.8 id，51.3 wa，0.0 hi，   0.5 si，0.0 st
  KiB Mem：总计8176996，使用8036792，140204免费，120缓冲   KiB掉期：总计6289404，二手3968236，免费2321168。 4044缓存Mem

     

PID用户PR NI VIRT RES SHR S％CPU％MEM TIME + COMMAND
   36 root 20 0 0 0 0 S 2.3 0.0   288：05.05 kswapd0
  3838 rrr 20 0 7791836 3.734g 612 S 2.0   47.9 330：08.65 redis-server
  17477 rrr 20 0 7792228 6.606g 364 D 1.0 84.7 0：43.49 redis-server

Answer 1

这非常有趣，因为我不记得曾经读过这些问题，所以发现根本原因可能非常有用。

因此，您在这里报告一个长时间处于活动状态的子进程，甚至继续分配内存。如果不是进程内存中的数据损坏，我没有解释这个问题，导致RDB进程找到意外情况并以某种方式永远循环。

几个问题：

1. 即使重新启动流程，是否会发生这种情况？ （但是，如果你可以避免重新开始而且你还没有重申，请不要这样做，否则我们可能不再理解根本原因。）
2. 当RDB保存处于活动状态时，您是否看到CPU使用率较高且使用ps / top运行进程？
3. 您是否可以尝试使用gdb -p <pid>中断进程并获取进程的堆栈跟踪？
4. 您是否可以提供Redis INFO输出来检查版本和其他配置事项并说明状态？
5. 在发生这种情况时，您可以检查free输出吗？

TLDR ：系统是否可能内存不足并且交换频繁？因此，子进程在保存RDB文件时访问了所有页面并强制所有内容都在Resident Set中。系统无法应对如此多的I / O，因此完成RDB保存需要很长时间。

编辑：我刚刚注意到你报告了内存信息：

KiB Mem：总计8176996，使用8036792，140204免费，120缓冲

因此系统内存不足并且像疯了一样交换，这导致了上述行为。随着RDB保存的开始，COW将使用大量额外的内存来推动服务器的内存限制。

感谢。