转：

Redis需要多少内存预留-内存占用多少才安全

上一篇文章，我已经尝试过，用设置的方式，去限制redis内存的占用大小，结果发现是不可行的。（redis不会区分冷热数据，保留冷数据在硬盘上）。那么如果要正常运行redis，就需要知道，redis最多可以占用多少内存，保留多少内存。

结论：

极限情况：留出一倍内存。比如你的redis数据占用了8G内存，那么你还需要再预留8G空闲内存。也就是内存需求是16G。内存占用率低于50%是最安全的。

普通情况：正常情况下，在序列化周期内，不会更改所有数据，只会有部分数据更改，那么，预留出可能产生的更改部分的空间，就行。如果实在要说一个数据的话，内存占用率低于75%都是安全的。

比如我们这个游戏服务器的，N台数据服务器之一的截图：

如上图，16G的内存，已经使用了64%了。但是实际上，在fork序列化的时候，只多占用了200多M的内存而已。因为只变动了200多M。 也就是说，使用内存使用率即便达到80%，也是安全的。因为Copy-On-Write就需要200M而已。

以下是扩展阅读，原文链接： https://searchdatabase.techtarget.com.cn/7-21572/

多留一倍内存是最安全的。
重写AOF文件和RDB文件的进程(即使不做持久化，复制到Slave的时候也要写RDB)会fork出一条新进程来，采用了操作系统的Copy-On-Write策略(如果父进程的内存没被修改，子进程与父进程共享Page。如果父进程的Page被修改, 会复制一份改动前的内容给新进程)，留意Console打出来的报告，如”RDB: 1215 MB of memory used by copy-on-write”。
在系统极度繁忙时，如果父进程的所有Page在子进程写RDB过程中都被修改过了，就需要两倍内存。
按照Redis启动时的提醒，设置 vm.overcommit_memory = 1 ，使得fork()一条10G的进程时，因为COW策略而不一定需要有10G的free memory.
当最大内存到达时，按照配置的Policy进行处理，
默认policy为volatile-lru， 对设置了expire time的key进行LRU清除(不是按实际expire
time)。如果沒有数据设置了expire time或者policy为noeviction，则直接报错，但此时系统仍支持get之类的读操作。
另外还有几种policy，比如volatile-ttl按最接近expire time的，allkeys-lru对所有key都做LRU。
原来2.0版的VM(将Value放到磁盘，Key仍然放在内存)，2.4版后又不支持了。（ps. 这是个坑。我以前记得有这么个东西）