redis 关闭 bgsave 后整个 web 响应时间提升 5 倍，这是个坑么？

[sujin190]

最近访问量略有点上涨（每日一千万左右），发现老是偶尔会有延迟很高的情况，超过一秒以上，一直找不出原因，昨天无意中发现出现时机居然和 redis 的 bgsave 一样，猜想和 redis 有点关系，于是关闭了 bgsave ，今天一看响应平均延时居然从原来的 110ms 左右下降到了 20ms 左右，我一直以为 redis 持久化是 fork 进程处理的，应该对正常处理请求不会有影响才是，感觉官方文档也是这么说的，难道是我理解的不对么？还是中间还有其他的坑呢？

[czheo]

bgsave 耗 cpu ，如果你的机器还跑了其它进程和 bgsave 跑到同一个 cpu core 上会慢是正常的吧。

[sujin190]

@czheo 8 核，就跑了一个 redis 实例

[defunct9]

redis 修改 cpu 亲和性

[killpanda]

印象里 bgsave 会阻塞吧。。

[SErHo]

创建子进程是要耗时的，你可以测下。《 Redis 实战》这本书的作者是这样写的：对于真实硬件、 VMWare 、 KVM 虚拟机 Redis 进程每占用 1G 内存，创建子进程的时间就要增加 10~20ms ， Xen 虚拟机大概 200~300 毫秒。

[sujin190]

@killpanda 不可能吧

[sujin190]

@SErHo 可是在 bgsave 过程中，响应延时都过秒了，也和那不一样啊，奇怪

[tczzjin]

你可以再起一台机器,作为 slave,然后在 slave 执行 bgsave.slave 本身不对外提供业务,应该会好很多

[Numbcoder]

bgsave 是 fork 的，但是比较耗 cpu ，可以把 bgsave 的频率降低点

[czheo]

@sujin190 过秒的话考虑可能是内存太小了？ bgsave 要消耗内存，所以内存使用会超出你的数据大小，最坏的情况会消耗 2 倍内存。

[500miles]

bgsave 虽然是 fork 进程处理的。。但处理时，发起大量 fsync 系统调用，主进程的 fsync 就也可能被阻塞

官方解释过这个问题。。 可以指定 bgsave 时主进程不要 fsync ，但也丧失一些安全性

[sujin190]

@tczzjin 现在就是这么干的，还不错

[sujin190]

@500miles 这个系统调用不是同步文件写到磁盘的么？主进程还会有这个调用？

[sujin190]

@500miles 内存只用了四分之一，应该不是这个问题

[onlineismy]

http://blog.nosqlfan.com/html/3537.html 不谢

[onlineismy]

bgsave 不会阻塞，是 fork 一个子进程，然后写磁盘：
“ RDB 需要经常 fork 子进程来保存数据集到硬盘上,当数据集比较大的时候,fork 的过程是非常耗时的,可能会导致 Redis 在一些毫秒级内不能响应客户端的请求.如果数据集巨大并且 CPU 性能不是很好的情况下,这种情况会持续 1 秒,AOF 也需要 fork,但是你可以调节重写日志文件的频率来提高数据集的耐久度.”

[onlineismy]

@sujin190 master 和 salve 之间的同步也是同步 master bgsaver 的 db 文件吧？

[sujin190]

@onlineismy 其实我知道这个过程，只是数据量和 fork 时间影响比我想象的大多了，所以是不是还有其他的坑呢

[sujin190]

@onlineismy 首次启动确实是，之后就不是了啊，直接 master 把操作命令同步发给 slave ，后面消耗就很小了

[freshlhy]

每日一千万 什么好玩的应用啊

[linoder]

kernel 没有关闭 cache 的话 bgsave 会占用相当大一部分内存

[sujin190]

@linoder 写缓存？这就是说用户空间内存使用加写缓存？

[Rosanta]

bgsave 会 fork 出子进程进行写磁盘操作，把内存里的数据倒进磁盘。但是因为操作系统是 copy on write 机制，你 bgsave 的过程里如果写请求太多的话，也会对服务有影响，最好确认下

[sujin190]

@Rosanta 恩，确实，虽然 redis 写请求大半，但每秒也不到一千，这小意思了吧