V2EX = way to explore
V2EX 是一个关于分享和探索的地方
Sign Up Now
For Existing Member Sign In
This topic created in 3550 days ago, the information mentioned may be changed or developed.
最近访问量略有点上涨（每日一千万左右），发现老是偶尔会有延迟很高的情况，超过一秒以上，一直找不出原因，昨天无意中发现出现时机居然和 redis 的 bgsave 一样，猜想和 redis 有点关系，于是关闭了 bgsave ，今天一看响应平均延时居然从原来的 110ms 左右下降到了 20ms 左右，我一直以为 redis 持久化是 fork 进程处理的，应该对正常处理请求不会有影响才是，感觉官方文档也是这么说的，难道是我理解的不对么？还是中间还有其他的坑呢？
 |
1
czheo Aug 7, 2016
bgsave 耗 cpu ，如果你的机器还跑了其它进程和 bgsave 跑到同一个 cpu core 上会慢是正常的吧。
|
 |
3
defunct9 Aug 7, 2016 via iPhone
redis 修改 cpu 亲和性
|
 |
4
killpanda Aug 7, 2016
印象里 bgsave 会阻塞吧。。
|
 |
5
SErHo Aug 7, 2016  1
创建子进程是要耗时的，你可以测下。《 Redis 实战》这本书的作者是这样写的：对于真实硬件、 VMWare 、 KVM 虚拟机 Redis 进程每占用 1G 内存，创建子进程的时间就要增加 10~20ms ， Xen 虚拟机大概 200~300 毫秒。
|
 |
8
tczzjin Aug 7, 2016
你可以再起一台机器,作为 slave,然后在 slave 执行 bgsave.slave 本身不对外提供业务,应该会好很多
|
 |
9
Numbcoder Aug 7, 2016
bgsave 是 fork 的，但是比较耗 cpu ，可以把 bgsave 的频率降低点
|
 |
11
500miles Aug 7, 2016
bgsave 虽然是 fork 进程处理的。。但处理时，发起大量 fsync 系统调用，主进程的 fsync 就也可能被阻塞
官方解释过这个问题。。 可以指定 bgsave 时主进程不要 fsync ，但也丧失一些安全性 |
 |
15
onlineismy Aug 8, 2016 1
|
|
16
onlineismy Aug 8, 2016
bgsave 不会阻塞，是 fork 一个子进程，然后写磁盘：
“ RDB 需要经常 fork 子进程来保存数据集到硬盘上,当数据集比较大的时候,fork 的过程是非常耗时的,可能会导致 Redis 在一些毫秒级内不能响应客户端的请求.如果数据集巨大并且 CPU 性能不是很好的情况下,这种情况会持续 1 秒,AOF 也需要 fork,但是你可以调节重写日志文件的频率来提高数据集的耐久度.” |
|
17
onlineismy Aug 8, 2016
@sujin190 master 和 salve 之间的同步也是同步 master bgsaver 的 db 文件吧？
|
 |
18
sujin190 OP @onlineismy 其实我知道这个过程，只是数据量和 fork 时间影响比我想象的大多了，所以是不是还有其他的坑呢
|
|
19
sujin190 OP @onlineismy 首次启动确实是，之后就不是了啊，直接 master 把操作命令同步发给 slave ，后面消耗就很小了
|
 |
20
freshlhy Aug 8, 2016
每日一千万 什么好玩的应用啊
|
 |
21
linoder Aug 9, 2016
kernel 没有关闭 cache 的话 bgsave 会占用相当大一部分内存
|
 |
23
Rosanta Aug 9, 2016
bgsave 会 fork 出子进程进行写磁盘操作，把内存里的数据倒进磁盘。但是因为操作系统是 copy on write 机制，你 bgsave 的过程里如果写请求太多的话，也会对服务有影响，最好确认下
|
Select Language