redis的内存陷阱

redis是个对内存依赖性很强的NoSql数据库，在内存足够的情况下性能出色

如果只有一台机子去部署redis，一定要特别小心。

比如我有台24G的服务器，理所当然我会将大量内存分配给redis。

比如20G的内存， 问题来了， 当你对redis插入数据后，redis会异步将数据dump到硬盘中

想起来很完美，问题是它会fork一个进程，并占去同样大小的内存，你需要的内存瞬间便为 20G+20G =40G

这时内存超过了物理内存的限制，马上会启动虚拟内存，我的机子上是8G虚拟内存，重点是这个是linux的虚拟内存，并不是redis自己的虚拟内存。

linux的虚拟内存 page很大，IO剧增，dump速度会非常慢，整个服务器的性能降到冰点，服务请求都会堵塞。最严重到机子坏掉。

对于单台机子最好是降低redis虚拟内存设置，page可以根据配置修改，这个虚拟内存比linux的虚拟内存好很多，因为page小很多。

如果你的redis既有读又有写，那么最好不要让redis占去大半的内存。

可以设置它的虚拟内存到8G，这还要根据你的key值大小的衡量，因为key是必须在内存中的，这样一来就算启用了虚拟内存，redis占去的实际内存也会超出设想。

天哪， 就是说必须给redis留出他本身需要一倍以上的内存，平时在不插入数据的时候，内存空着不用，浪费。

此外官方文档中建议对key小，value很大的数据设置虚拟内存。

另外master/slave不是很成熟，目前只支持主从，Redis在master是非阻塞模式，也就是说在slave执行数据同步的时候，master是可以接受客户端的请求的，并不影响同步数据的一致性，然而在slave端是阻塞模式的，slave在同步master数据时，并不能够响应客户端的查询

可以根据master/slave的特点，master不dump，它只负责写数据，让slave去dump

 

楼主，有没一些具体的数据做说明呢？比如你观测到linux系统状态数据，或者截图啥的

有2个疑问：
1. 它fork的子进程，为什么会使用相同的内存大小进行dump操作，作者不至于这么蠢吧。
2. 疑惑的是linux针对运行进程都有虚拟内存的概念，就像你准备开2G的内存，操作系统并不会立即给你那么大的实际内存，它只给你一个虚的内存地址，到真实用的时候才会去换入内存page页。所以即使fork子进程的时候，需要那么大的内存，系统也不会立马分配给你。不知你提的page是不是也是内存page页的概念？

http://yiihsia.iteye.com/admin/pictures  我截了图你可以看下。

第一个问题，主进程继续提供服务，同时fork出来的进程把数据dump到磁盘里，这样可以保证dump的时候数据不再变化的同时能够继续提供读写服务

第二个问题，redis有自己的虚拟内存，相对linux的VM更加轻量，但是在写密集的时候，redis的VM的性能不佳，linux的VM更加悲剧

第一个问题，大致明白了。不过那图片看不到。

第二个可能比较深，我自己再了解一下

非常感谢解答

关于linux的虚拟内存我也没有深入了解

楼主说：“想起来很完美，问题是它会fork一个进程，并占去同样大小的内存，你需要的内存瞬间便为 20G+20G =40G”


这个应该不对吧？fork子进程之后，子进程和父进程是共享内存的，并且是采用copy on write的方式处理被修改的内容。

如redis中，fork子进程之后，父进程的某一个key的内容被修改了，那么内核只是对当前key的内容复制一份然后再进行修改。。。

裔帝，真是无处不在。

虽然不清楚具体，不过作者应该不会这么傻的。

http://code.google.com/p/redis/issues/detail?id=150  google上有讨论

前面有些不对的地方，这里比较全面 对redis数据持久化的一些想法