summaryrefslogtreecommitdiff
path: root/redis.conf
diff options
context:
space:
mode:
authorWang Yuan <wangyuan21@baidu.com>2021-08-30 15:24:53 +0800
committerGitHub <noreply@github.com>2021-08-30 10:24:53 +0300
commit9a0c0617f10ebb6cd5bf82f5f4f7049e7ff0a3ce (patch)
treefbbf767d9291f4e0ef1e49064320246e9390cba9 /redis.conf
parentaefbc23451ae8d0c7503f2c3cb014bfd5b07b4ed (diff)
downloadredis-9a0c0617f10ebb6cd5bf82f5f4f7049e7ff0a3ce.tar.gz
Use sync_file_range to optimize fsync if possible (#9409)
We implement incremental data sync in rio.c by call fsync, on slow disk, that may cost a lot of time, sync_file_range could provide async fsync, so we could serialize key/value and sync file data at the same time. > one tip for sync_file_range usage: http://lkml.iu.edu/hypermail/linux/kernel/1005.2/01845.html Additionally, this change avoids a single large write to be used, which can result in a mass of dirty pages in the kernel (increasing the risk of someone else's write to block). On HDD, current solution could reduce approximate half of dumping RDB time, this PR costs 50s for dump 7.7G rdb but unstable branch costs 93s. On NVME SSD, this PR can't reduce much time, this PR costs 40s, unstable branch costs 48s. Moreover, I find calling data sync every 4MB is better than 32MB.
Diffstat (limited to 'redis.conf')
-rw-r--r--redis.conf4
1 files changed, 2 insertions, 2 deletions
diff --git a/redis.conf b/redis.conf
index 84f45fdb7..09107dcea 100644
--- a/redis.conf
+++ b/redis.conf
@@ -1881,13 +1881,13 @@ hz 10
dynamic-hz yes
# When a child rewrites the AOF file, if the following option is enabled
-# the file will be fsync-ed every 32 MB of data generated. This is useful
+# the file will be fsync-ed every 4 MB of data generated. This is useful
# in order to commit the file to the disk more incrementally and avoid
# big latency spikes.
aof-rewrite-incremental-fsync yes
# When redis saves RDB file, if the following option is enabled
-# the file will be fsync-ed every 32 MB of data generated. This is useful
+# the file will be fsync-ed every 4 MB of data generated. This is useful
# in order to commit the file to the disk more incrementally and avoid
# big latency spikes.
rdb-save-incremental-fsync yes