diff options
author | Wang Yuan <wangyuan21@baidu.com> | 2021-08-30 15:24:53 +0800 |
---|---|---|
committer | GitHub <noreply@github.com> | 2021-08-30 10:24:53 +0300 |
commit | 9a0c0617f10ebb6cd5bf82f5f4f7049e7ff0a3ce (patch) | |
tree | fbbf767d9291f4e0ef1e49064320246e9390cba9 /redis.conf | |
parent | aefbc23451ae8d0c7503f2c3cb014bfd5b07b4ed (diff) | |
download | redis-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.conf | 4 |
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 |