Home / server / Questions / 569376
Accepted
Paiboon Panusbordee
Asked: 2014-01-24 07:06:31 +0800 CST

My redis' fork time is slow and impact query performance a little. What should I do to check?

  • 772

I used redis with RDB option only. It used 2GB of memory. When it forked, it used about 10 seconds to completely save the file. When I check up with redis.io site, I found this latency stat:

- 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).

I used dedicated server Xeon E3-1240 machines. Compare to these results above, it used lots more time to save. Is it because all my keys are hash? What should I do to reduce latency and reduce impact to main Redis process to query?

latency

1 Answers

  1. Best Answer

    from the Redis INFO output, the relevant metrics for fork time and save to disk are:

    rdb_last_bgsave_time_sec:0
latest_fork_usec:545

    The redis.io notes talk about the fork time, not the time taken to fully persist the file on disk.

    The time taken to fully persist on disk depends on the speed of both your CPU and the storage (disk or disks) itself. You'd need to look at vmstat or iostat output (assuming you're on Linux). In the author's case it's 2GB to store on disk after all... Whether the keys are Hash or not does not come into play. Hash is usually a good choice for fitting more into memory however.

    The save-to-disk time can have very little relevance or alot of relevance... it depends on how affected your Redis process is during the save-to-disk process..

    But again; do note that the fork time is usually what is the actual problem, even if it's milliseconds, that's when the latency usually happens, since it's blocking during the (brief) memory copy. The actual save to disk, like I said, may or may not be something you need to worry about at all. It's performed in a background thread.

    • 0