我只用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机器。 与上面的这些结果相比，它使用了更多的时间来保存。 是因为我所有的密钥都是散列吗？ 我应该怎么做才能减less延迟并减less对Redis进程查询的影响？
从Redis INFO输出中，分叉时间和保存到磁盘的相关度量标准是：
rdb_last_bgsave_time_sec:0 latest_fork_usec:545
redis.io笔记谈论fork时间 ，而不是完全坚持文件在磁盘上的时间。
完全坚持在磁盘上花费的时间取决于您的CPU和存储（磁盘或磁盘）本身的速度。 您需要查看vmstat或iostat输出（假设您在Linux上）。 在作者的情况下，2GB的存储在磁盘上…无论密钥是哈希还是不起作用。 哈希通常是一个很好的select，但更适合于内存。
保存到磁盘的时间可以有很less的相关性或很多相关性…这取决于在保存到磁盘过程中您的Redis进程的影响。
但是， 请注意， fork时间通常是实际问题，即使是毫秒，通常也会发生延迟 ，因为它在（简短）内存复制期间被阻塞。 像我说的那样，真正的保存到磁盘可能是或者可能不是你需要担心的东西。 它在后台线程中执行。