ref: http://blog.nosqlfan.com/html/324.html?ref=rediszt

这是某人的一个实际运维经验，很不错的！

本文转自一米六二博客（nice name），是将用在较大型数据上的一个实例，作者为yahoo!中国的后端工程师，其收集整理的在亦在网上广为流传。

原文链接：

Redis 改版的项目上线有两个月了，记录一下Redis 相关的经验，也给大家一个参照:

我们的Redis Server是一主一从，使用R710的机器，8核心，24G内存。 每天约插入200万左右的数据，现在库里有3000万条纪录，占用了9G的内存。由于现在每天内存增长太快，担心很快会无法负载，因此写了脚本每天将过期数据删除。

现在运行中的问题:

1、Redis运行基本稳定，从没有自己中断过服务，php脚本去set的话大概1秒钟能设置1万条小数据，并没有官方给出的数据高。但是修改配置后大重启服务时大概需要1到2分钟才能完全将硬盘中的数据加载到内存中去，在加载完之前，Redis不能提供服务。

2、Redis的默认配置中，每60秒如果纪录更改数达到1万条就需要dump到硬盘中去，但实际上由于超过了这个数，我们的Redis几乎不停地 在dump数据到硬盘上。dump数据到硬盘时，我估计为了达到一个原子的效应，避免数据丢失，Redis是先把数据dump到一个临时文件，然后重命名 为你在配置文件设定的数据文件名。而前面说到，加载数据要1到2分钟，dump数据应该也在1分钟左右吧。dump出来的文件差不多1到2个G。这样，服 务器几乎一直保持着每分钟写一个2G的文件的这种IO的负载。磁盘基本不闲着。

3、还是在dump中，除开磁盘不闲着以外，CPU也一路飙升:Redis是fork一个子进程来dump数据到硬盘，原有进程占用30%+的CPU，而dump数据的子进程单独享用了一个CPU核心，cpu占用100%。

4、 Redis在dump数据的时候，是fork子进程，这样产生一个问题:Redis本向占用了9G的内存，在dump数据时又fork一个进程，子进程继 承了内存分配，也占用了9G的内存…。Redis一下子占用了18G的内存了。（NoSQLFan：由于fork调用的内存会采用操作系统的COW机制， 所以内存不会马上加倍，只有在最坏的情况下，也就是在dump的时候主进程中的数据完全被修改了才COPY出两倍的内存来。）

发现这些问题后，我修改了Redis的配置文件，设置为30分钟内只要有一次写修改就dump数据，这样系统负载大幅减轻了。

处于设想中的想法:

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/7916042/viewspace-1057410/，如需转载，请注明出处，否则将追究法律责任。