Manually Manage Direct Write Buffer in Frozen Cache Writes #70399
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
Manually managing the buffer has a number of upsides for us and no direct downsides as far as I can see. * We limit the number of syscalls for large writes by a factor of up to `8` (in pratice it's probably mostly `8` when writing larger amounts of data) * Since we limit the write thread count to 28 the amount of direct memory used is limited * We eliminate the copying from heap -> off-heap under the lock in the channel's positional write * We eliminate allocating `ByteBuffer` instances in a hot loop when writing large regions
original-brownbear
added
>non-issue
:Distributed Coordination/Snapshot/Restore
elasticmachine
added
the
Team:Distributed (Obsolete)
|
Pinging @elastic/es-distributed (Team:Distributed) |
ywelsch
reviewed
Mar 18, 2021
| return fc.write(byteBuffer, start); | ||
| byteBuffer.flip(); | ||
| int written = fc.write(byteBuffer, start); | ||
| byteBuffer.clear(); |
There was a problem hiding this comment.
Can we clear buffer if not everything was written? Or would we have to assert that buffer.remaining() is 0 here and that written == old(buffer.remaining())?
There was a problem hiding this comment.
I think just assert byteBuffer.hasRemaining() == false; is sufficient. We do assert that the sum of all writes matches up in the callers anyway and we don't have to add another variable just for the assertion here. I pushed 34b179e for that.
original-brownbear
added a commit
to original-brownbear/elasticsearch
that referenced
this pull request
Mar 18, 2021
…0399) Manually managing the buffer has a number of upsides for us and no direct downsides as far as I can see. * We limit the number of syscalls for large writes by a factor of up to `8` (in practice it's probably mostly `8` when writing larger amounts of data) * Since we limit the write thread count to 28 the amount of direct memory used is limited * We eliminate the copying from heap -> off-heap under the lock in the channel's positional write * We eliminate allocating `ByteBuffer` instances in a hot loop when writing large regions
original-brownbear
added a commit
to original-brownbear/elasticsearch
that referenced
this pull request
Mar 18, 2021
…0399) Manually managing the buffer has a number of upsides for us and no direct downsides as far as I can see. * We limit the number of syscalls for large writes by a factor of up to `8` (in practice it's probably mostly `8` when writing larger amounts of data) * Since we limit the write thread count to 28 the amount of direct memory used is limited * We eliminate the copying from heap -> off-heap under the lock in the channel's positional write * We eliminate allocating `ByteBuffer` instances in a hot loop when writing large regions
original-brownbear
added a commit
that referenced
this pull request
Mar 18, 2021
…70558) Manually managing the buffer has a number of upsides for us and no direct downsides as far as I can see. * We limit the number of syscalls for large writes by a factor of up to `8` (in practice it's probably mostly `8` when writing larger amounts of data) * Since we limit the write thread count to 28 the amount of direct memory used is limited * We eliminate the copying from heap -> off-heap under the lock in the channel's positional write * We eliminate allocating `ByteBuffer` instances in a hot loop when writing large regions
original-brownbear
added a commit
that referenced
this pull request
Mar 18, 2021
…70559) Manually managing the buffer has a number of upsides for us and no direct downsides as far as I can see. * We limit the number of syscalls for large writes by a factor of up to `8` (in practice it's probably mostly `8` when writing larger amounts of data) * Since we limit the write thread count to 28 the amount of direct memory used is limited * We eliminate the copying from heap -> off-heap under the lock in the channel's positional write * We eliminate allocating `ByteBuffer` instances in a hot loop when writing large regions
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Manually managing the buffer has a number of upsides for us and no direct downsides as far as I can see:
8(in practice it's probably mostly8when writing larger amounts of data)ByteBufferinstances in a hot loop when writing large regions