redis迁移相关问题

现象

1183:M 17 Sep 13:54:54.069 * Slave 172.17.1.49:7480 asks for synchronization
1183:M 17 Sep 13:54:54.070 * Full resync requested by slave 172.17.1.49:7480
1183:M 17 Sep 13:54:54.070 * Starting BGSAVE for SYNC with target: disk
1183:M 17 Sep 13:54:54.070 # Can't save in background: fork: Cannot allocate memory
#无法分配内存
1183:M 17 Sep 13:54:54.070 # BGSAVE for replication failed

解决

这个错误是因为，redis有个默认选项
stop-writes-on-bgsave-error yes
在默认情况下，如果rdb snapshots持久化出现问题，设置这个参数后，redis不允许用户进行任何更新

不彻底的解决方式，将这个选项改为no
stop-writes-on-bgsave-error no
这样只是当redis写硬盘快照出错时，可以让用户继续做更新操作，但是写硬盘仍然是失败的。

彻底解决方式
编辑/etc/sysctl.conf添加
vm.overcommit_memory=1
执行sysctrl -p 使其生效

 

原因

vm.overcommit_memory 这个参数又是干什么的呢？

Linux对大部分申请内存的请求都回复"yes"，以便能跑更多更大的程序。因为申请内存后，并不会马上使用内存，将这些不会使用的空闲内存分配给其它程序使用，以提高内存利用率，这种技术叫做Overcommit。一般情况下，当所有程序都不会用到自己申请的所有内存时，系统不会出问题，但是如果程序随着运行，需要的内存越来越大，在自己申请的大小范围内，不断占用更多内存，直到超出物理内存，当linux发现内存不足时，会发生OOM killer(OOM=out-of-memory)。它会选择杀死一些进程(用户态进程，不是内核线程，哪些占用内存越多，运行时间越短的进程越有可能被杀掉)，以便释放内存。
 

当oom-killer发生时，linux会选择杀死哪些进程？选择进程的函数是oom_badness函数(在mm/oom_kill.c中)，该函数会计算每个进程的点数(0~1000)。点数越高，这个进程越有可能被杀死。每个进程的点数跟（/proc/<pid>/oom_adj）oom_score_adj有关，而且oom_score_adj可以被设置(-1000最低，1000最高)。

 

当发生oom killer时，会将记录在系统日志中/var/log/messages

 

Out of memory: Kill process 9682 (mysqld) score 9 or sacrifice child
Killed process 9682, UID 27, (mysqld) total-vm:47388kB, anon-rss:3744kB, file-rss:80kB
httpd invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0

在什么条件下，linux会发现内存不足呢？

在Linux下有个CommitLimit 用于限制系统应用使用的内存资源:

[root@iZuf6c2qeenlv7dqgioq2eZ bin]# grep -i commit /proc/meminfo
CommitLimit:      961120 kB
Committed_AS:    1514856 kB

其中：
CommitLimit是一个内存分配上限，
Committed_AS是已经分配的内存大小。

虚拟内存算法：
 

    CommitLimit = 物理内存 * overcommit_ratio(/proc/sys/vm/overcmmit_ratio，默认50，即50%) + swap大小  

它是由内核参数overcommit_ratio的控制的,当我们的应用申请内存的时候，当出现以下情况：
 

    应用程序要申请的内存 + 系统已经分配的内存（也就是Committed_AS）> CommitLimit  

这时候就是内存不足，到了这里，操作系统要怎么办，就要祭出我们的主角“overcommit_memory”参数了（/proc/sys/vm/overcommit_memory）；
 

• vm.overcommit_memory = 0   启发策略

比较 此次请求分配的虚拟内存大小和系统当前空闲的物理内存加上swap，决定是否放行。系统在为应用进程分配虚拟地址空间时，会判断当前申请的虚拟地址空间大小是否超过剩余内存大小，如果超过，则虚拟地址空间分配失败。因此，也就是如果进程本身占用的虚拟地址空间比较大或者剩余内存比较小时，fork、malloc等调用可能会失败。
 

•  vm.overcommit_memory = 1 允许overcommit

直接放行，系统在为应用进程分配虚拟地址空间时，完全不进行限制，这种情况下，避免了fork可能产生的失败，但由于malloc是先分配虚拟地址空间，而后通过异常陷入内核分配真正的物理内存，在内存不足的情况下，这相当于完全屏蔽了应用进程对系统内存状态的感知，即malloc总是能成功，一旦内存不足，会引起系统OOM杀进程，应用程序对于这种后果是无法预测的。
 

• vm.overcommit_memory = 2 禁止overcommit

根据系统内存状态确定了虚拟地址空间的上限，由于很多情况下，进程的虚拟地址空间占用远大于其实际占用的物理内存，这样一旦内存使用量上去以后，对于一些动态产生的进程(需要复制父进程地址空间)则很容易创建失败，如果业务过程没有过多的这种动态申请内存或者创建子进程，则影响不大，否则会产生比较大的影响 。这种情况下系统所能分配的内存不会超过上面提到的CommitLimit大小，如果这么多资源已经用光，那么后面任何尝试申请内存的行为都会返回错误，这通常意味着此时没法运行任何新程序。

在小内存的进程上做fork, 不需要太多资源. 但当这个进程的内存空间以G为单位时, fork就成为一件很恐怖的操作.
在16G内存的足迹上fork 14G的进程, 系统肯定Cannot allocate memory.
主机的Redis 改动的越频繁 fork进程也越频繁, 所以一直在Cannot allocate memory

对redis的影响

    Redis的数据回写机制分同步和异步两种，

    同步回写即SAVE命令，主进程直接向磁盘回写数据。在数据大的情况下会导致系统假死很长时间，所以一般不是推荐的。

    异步回写即BGSAVE命令，主进程fork后，复制自身并通过这个新的进程回写磁盘，回写结束后新进程自行关闭。由于这样做不需要主进程阻塞，系统不会假死，一般默认会采用这个方法

    默认采用方式2，所以如果我们要将数据刷到硬盘上，这时redis分配内存不能太大，否则很容易发生内存不够用无法fork的问题；
设置一个合理的写磁盘策略，否则写频繁的应用，也会导致频繁的fork操作，对于占用了大内存的redis来说，fork消耗资源的代价是很大的；