log: use fdatasync instead of fsync where possible #263
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jfriesse
reviewed
Jul 28, 2017
| break | ||
| fi | ||
| file_sync=fsync;; | ||
| fsync) |
Member
There was a problem hiding this comment.
I would suggest to add comment like "FALLTHROUGH is intentional"
Contributor
Author
There was a problem hiding this comment.
There were other issues (fixed now) but I'd say the iterated fallback
scheme is quite recognizable.
Contributor
Author
There was a problem hiding this comment.
Ok, I'll add a brief explanation prior to start of the show.
jnpkrn
force-pushed
the
log-fdatasync
branch
3 times, most recently
from
ca83aec to
55efe05
Compare
Using years-old benchmark attached to PostreSQL ML[1], I've observed tiny bit more than double boost in speed when using fdatasync instead of traditional fsync, on two Linux machines, each equipped with an SSD. While the observation may be disputable (there are various interpretations to what "synchronized I/O" actually means), by logical extension of what the two are supposed to do, one can expect fdatasync will perform no worse than fsync. Having the timestamps correct is really not a priority, compared to timely processing of the message stream. So let's use it whenever possible with QB_LOG_CONF_FILE_SYNC requested. As an aside, PostreSQL seems to be be using "fdatasync" method of updating out to disk by default on Linux till today[2]. [1] https://www.postgresql.org/message-id/1095055866.414539fadb90d@webmail.rawbw.com https://www.postgresql.org/message-id/attachment/20659/syncbench.c [2] https://www.postgresql.org/docs/current/static/runtime-config-wal.html#GUC-WAL-SYNC-METHOD Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Using years-old benchmark attached to PostreSQL ML[1], I've observed
tiny bit more than double boost in speed when using fdatasync instead of
traditional fsync, on two Linux machines, each equipped with an SSD.
While the observation may be disputable (there are various
interpretations to what "synchronized I/O" actually means), by logical
extension of what the two are supposed to do, one can expect fdatasync
will perform no worse than fsync. Having the timestamps correct is
really not a priority, compared to timely processing of the message
stream. So let's use it whenever possible with QB_LOG_CONF_FILE_SYNC
requested.
[1] https://www.postgresql.org/message-id/1095055866.414539fadb90d@webmail.rawbw.com
https://www.postgresql.org/message-id/attachment/20659/syncbench.c