我仅使用了带 RDB 选项的 redis。它使用了 2GB 内存。当它分叉时,它花了大约 10 秒的时间才完全保存文件。当我检查 redis.io 网站时,我发现了以下延迟统计数据:
- Linux beefy VM on VMware 6.0GB RSS forked in 77 milliseconds (12.8 milliseconds per GB).
- Linux running on physical machine (Unknown HW) 6.1GB RSS forked in 80 milliseconds (13.1 milliseconds per GB)
- Linux running on physical machine (Xeon @ 2.27Ghz) 6.9GB RSS forked into 62 millisecodns (9 milliseconds per GB).
- Linux VM on 6sync (KVM) 360 MB RSS forked in 8.2 milliseconds (23.3 millisecond per GB).
- Linux VM on EC2 (Xen) 6.1GB RSS forked in 1460 milliseconds (239.3 milliseconds per GB).
- Linux VM on Linode (Xen) 0.9GBRSS forked into 382 millisecodns (424 milliseconds per GB).
我使用了专用服务器 Xeon E3-1240 机器。与上面的结果相比,它花费了更多时间来保存。是因为我的所有键都是哈希吗?我应该怎么做才能减少延迟并减少对主 Redis 进程查询的影响?
答案1
来自 Redis信息输出,fork 时间和保存到磁盘的相关指标是:
rdb_last_bgsave_time_sec:0
latest_fork_usec:545
这redis.io笔记谈论分叉时间,而不是将文件完全保存在磁盘上所花费的时间。
完全保存在磁盘上所需的时间取决于 CPU 和存储(磁盘或多个磁盘)本身的速度。您需要查看状态监测或者iostat输出(假设您使用的是 Linux)。在作者的例子中,磁盘上存储的数据毕竟是 2GB... 密钥是否为哈希并不重要。不过,哈希通常是将更多数据放入内存的好选择。
保存到磁盘的时间可能相关性很小或很大......这取决于您的 Redis 进程在保存到磁盘过程中受到的影响程度。
但再次强调,请注意分叉时间通常是实际的问题,即使是几毫秒,那时潜伏通常会发生这种情况,因为它在(短暂的)内存复制期间被阻塞。正如我所说,实际保存到磁盘可能是也可能根本不是您需要担心的事情。它是在后台线程中执行的。