RedisShake icon indicating copy to clipboard operation
RedisShake copied to clipboard

讨论: v4 性能提升

Open Zheaoli opened this issue 7 months ago • 4 comments

目前经过元旦的几天测试和 profile,有这样一些想法

  1. 目前经过 Profile,发现主要读侧的瓶颈还是在需要将文件写 file buffer 中,在云服务上,默认走 EBS 这样的存储,性能会额外的低下,同时会引发2的问题
  2. 因为1导致写入性能成为瓶颈,在模拟 SLAVE 时,容易出现 source instance 中 output buffer for replica 直接炸了,导致链接 RESET 的情况

我自己目前的看法是这样:

  1. #744 我觉得会很有用,但是实现可能需要讨论一下
  2. 目前 file buffer 我理解是有两个作用,1 可以让人后续使用 aof_reader 进行同步,2 减少内存使用。这里我觉得可以将 file buffer 作为可选项,我们同样可以实现 sized memory buffer。让用户自行选择

不过 reader 最终的改造需要在 Writer 并行写入改造完成后才能体现,这样是我在犹豫的地方

Zheaoli avatar Jan 01 '24 22:01 Zheaoli

是这样的,我上次测试也发现云上环境云盘的低带宽会构成瓶颈:

  1. 保存 dump.rdb 阶段需要较高的云盘写带宽,这个阶段耗时较长会导致源端 Redis 的 output buffer 一直堆积。
  2. 保存 aof 阶段对云盘带宽需求不高,一般 Redis 的写带宽不会很高,当然也有特殊情况。

可以考虑 dump.rdb 保存到内存,数 G 的内存空间可以接受。

suxb201 avatar Jan 02 '24 01:01 suxb201

  1. 目前 file buffer 我理解是有两个作用,1 可以让人后续使用 aof_reader 进行同步,2 减少内存使用。这里我觉得可以将 file buffer 作为可选项,我们同样可以实现 sized memory buffer。让用户自行选择

同样考虑过这点,是否可以增加不落盘的方式提供给用户选择。而且通过golang的有缓冲channel,连接reader和writer,可以天然的拥有背压的功能,内存占用是可控的

jjz921024 avatar Jan 02 '24 03:01 jjz921024

这里我考虑的是将 buffer 管理这一块抽象出来,做一个 BufferManager,支持两种模式,一种是 Memory Buffer,一种是 File Buffer

Zheaoli avatar Jan 02 '24 14:01 Zheaoli

Does this meet the demand?
https://github.com/CodisLabs/redis-port/tree/redis-4.x-cgo/pkg/libs/pipe

VonAlex avatar Mar 07 '24 07:03 VonAlex