Redis中报错类似
16149:M 05 Apr 09:26:25.085 * 1 changes in 3600 seconds. Saving...
16149:M 05 Apr 09:26:25.085 # Can't save in background: fork: Cannot allocate memory
这个是因为，redis有个默认的选项：
stop-writes-on-bgsave-error yes
这个选项默认情况下，如果在RDB snapshots持久化过程中出现问题，设置该参数后，Redis是不允许用户进行任何更新操作。
不彻底的解决方式是，将这个选项改为false
stop-writes-on-bgsave-error false
但是这样只是当redis写硬盘快照出错时，可以让用户继续做更新操作，但是写硬盘仍然是失败的；
彻底的解决方式
编辑文件 /etc/sysctl.conf 添加：
vm.overcommit_memory=1
执行sysctl -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大小，如果这么多资源已经用光，那么后面任何尝试申请内存的行为都会返回错误，这通常意味着此时没法运行任何新程序。
前面讲了一大堆参数，那么这些参数又是怎么影响redis的呢？
Redis的数据回写机制分同步和异步两种，
同步回写即SAVE命令，主进程直接向磁盘回写数据。在数据大的情况下会导致系统假死很长时间，所以一般不是推荐的。
异步回写即BGSAVE命令，主进程fork后，复制自身并通过这个新的进程回写磁盘，回写结束后新进程自行关闭。由于这样做不需要主进程阻塞，系统不会假死，一般默认会采用这个方法。
默认采用方式2，所以如果我们要将数据刷到硬盘上，这时redis分配内存不能太大，否则很容易发生内存不够用无法fork的问题；
设置一个合理的写磁盘策略，否则写频繁的应用，也会导致频繁的fork操作，对于占用了大内存的redis来说，fork消耗资源的代价是很大的；
这个问题在于swap太小，当时查看swap只有200MB。解决方式是从lv_root中减掉10GB，然后增加到lv_swap中去。
问题分析，grep -i commit /proc/meminfo中看到Committed_AS>CommitLimit，而
CommitLimit = 物理内存 * overcommit_ratio(/proc/sys/vm/overcmmit_ratio，默认50，即50%) + swap大小
所以这就意味着是swap空间不够，因此方案是增加swap。
问题结果过程中重要命令如下：
[root@hadoop1 ~]# lvs
LV VG Attr LSize Pool Origin Data% Move Log Cpy%Sync Convert
lv_root VolGroup -wi-ao---- 99.31g
lv_swap VolGroup -wi-ao---- 204.00m
apphome_lv appvg -wi-ao---- 50.00g
filevault_lv appvg -wi-ao---- 40.00g
[root@hadoop1 ~]#
[root@hadoop1 ~]# lvresize -L-10G VolGroup/lv_root
WARNING: Reducing active and open logical volume to 89.31 GiB
THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce lv_root? [y/n]: y
Reducing logical volume lv_root to 89.31 GiB
Logical volume lv_root successfully resized
[root@hadoop1 ~]# lvs
LV VG Attr LSize Pool Origin Data% Move Log Cpy%Sync Convert
lv_root VolGroup -wi-ao---- 89.31g
lv_swap VolGroup -wi-ao---- 204.00m
apphome_lv appvg -wi-ao---- 50.00g
filevault_lv appvg -wi-ao---- 40.00g
[root@hadoop1 ~]# lvresize -L+10G VolGroup/lv_swap
Extending logical volume lv_swap to 10.20 GiB
Logical volume lv_swap successfully resized
[root@hadoop1 ~]#
[root@hadoop1 ~]#
[root@hadoop1 ~]# lvs
LV VG Attr LSize Pool Origin Data% Move Log Cpy%Sync Convert
lv_root VolGroup -wi-ao---- 89.31g
lv_swap VolGroup -wi-ao---- 10.20g
apphome_lv appvg -wi-ao---- 50.00g
filevault_lv appvg -wi-ao---- 40.00g
[root@hadoop1 ~]#
[root@hadoop1 ~]# mkswap /dev/VolGroup/lv_swap
/dev/VolGroup/lv_swap: Device or resource busy
[root@hadoop1 ~]#
[root@hadoop1 etc]# swapoff -v /dev/VolGroup/lv_swap
swapoff on /dev/VolGroup/lv_swap
[root@hadoop1 etc]#
[root@hadoop1 etc]# mkswap /dev/VolGroup/lv_swap
mkswap: /dev/VolGroup/lv_swap: warning: don't erase bootbits sectors
on whole disk. Use -f to force.
Setting up swapspace version 1, size = 10694652 KiB
no label, UUID=1f4d708f-fb1b-420c-9514-e05cb41c42cd
[root@hadoop1 etc]#
[root@hadoop1 etc]# swapon /dev/VolGroup/lv_swap
[root@hadoop1 etc]# free
total used free shared buffers cached
Mem: 8061748 7206232 855516 0 130248 2434436
-/+ buffers/cache: 4641548 3420200
Swap: 10694648 0 10694648
[root@hadoop1 etc]#
[root@hadoop1 etc]# free -g
total used free shared buffers cached
Mem: 7 7 0 0 0 2
-/+ buffers/cache: 4 3
Swap: 10 0 10
[root@hadoop1 etc]# free
total used free shared buffers cached
Mem: 8061748 7895092 166656 0 124056 3017144
-/+ buffers/cache: 4753892 3307856
Swap: 10694648 0 10694648
网友评论