我有两个redis服务器运行在同一台机器上。第二个日志文件有几个实例,其通知如下:
[50818] 19 Feb 06:41:05.007 * 10 changes in 300 seconds. Saving...
[50818] 19 Feb 06:41:05.007 # Can't save in background: fork: Cannot allocate memory相反,第一个日志文件仅包含成功的DB保存。如果我没有记忆,我估计两人都会有相似的日志。我很困惑,只有一个有这个问题,另一个没有。有什么线索吗?
此外,研究还导致了这篇博客文章,它认为,如果我在命令行上执行sysctl vm.overcommit_memory=1,这个问题可以得到改善。没有解释这有什么帮助。有人能解释一下红色的背景下发生了什么吗?
发布于 2017-03-01 19:54:09
根据Redis常见问题:
Linux下的后台保存失败了,即使我有大量的空闲内存! 简短答覆:
echo 1 > /proc/sys/vm/overcommit_memory:) 现在又长了一个: 在现代操作系统中,Redis后台保存模式依赖于叉的复制-写语义: Redis叉(创建子进程)是父进程的精确副本。子进程将DB转储到磁盘上,最后退出。从理论上讲,子进程应该使用与父进程相同的内存,但实际上,由于大多数现代操作系统实现的复制即写语义,父进程和子进程将共享公共内存页。只有当页在子页或父页中发生更改时,它才会被复制。从理论上讲,当子进程保存时,所有页面都可能发生变化,因此Linux无法预先知道子进程将占用多少内存,因此,如果overcommit_memory设置为零叉,那么除非有足够多的空闲RAM来真正复制所有父内存页,否则就会失败,结果是,如果您有一个3GB的Redis数据集和2GB的空闲内存,它就会失败。将overcommit_memory设置为1可以使Linux放松并以更乐观的分配方式执行分叉,这确实是您对Redis的要求。 了解Linux以及overcommit_memory和overcommit_ratio的其他替代方案的一个很好的来源是红帽杂志“理解虚拟内存”中的经典。请注意,本文为overcommit_memory设置了1和2个配置值:请参阅proc(5)手册页,以获得可用值的正确含义。
https://stackoverflow.com/questions/42502636
复制相似问题