1

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?

Paiboon Panusbordee
  • 167
  • 1
  • 10
  • That table comes from [an article](http://redis.io/topics/latency) with a number of possible reasons for latency. Have you investigated all of those already? – HBruijn Nov 28 '14 at 14:47

1 Answers1

0

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.

fridh
  • 46
  • 2
  • fridh, thanks for your helpful answer. I don't get it why people are being so rude to you, nor why they claim this does not provide an answer to the OP's question. +1 – Bastian Voigt Oct 15 '15 at 07:04