Recovery buffer size 16B smaller#50100
Conversation
G1GC will use humongous allocations when an allocation exceeds half the chosen region size, which is minimum 1MB. By reducing the recovery buffer size by 16 bytes we ensure that the recovery buffer is never allocated as a humongous allocation.
|
Pinging @elastic/es-distributed (:Distributed/Recovery) |
|
We generate one such byte array per shard recovery on source. Not a lot of activity, but still I felt like the right thing to do here was to make the buffer 16 bytes smaller since it is unlikely to affect recovery speed. A separate issue is that as far as I can see we allocate new byte arrays currently on the target for every chunk, since |
This is correct. I have been working on a mechanism to prevent these allocations (probably for peer recovery file chunks and index operations). It should be opened pretty soon. |
|
|
Scratch my last comment, it looks like that async thing is only for testing simulation purposes. |
original-brownbear
left a comment
There was a problem hiding this comment.
I'm not convinced this will have much if any practical impact but I don't see a downside either
=> LGTM :)
G1GC will use humongous allocations when an allocation exceeds half the chosen region size, which is minimum 1MB. By reducing the recovery buffer size by 16 bytes we ensure that the recovery buffer is never allocated as a humongous allocation.
G1GC will use humongous allocations when an allocation exceeds half the chosen region size, which is minimum 1MB. By reducing the recovery buffer size by 16 bytes we ensure that the recovery buffer is never allocated as a humongous allocation.
G1GC will use humongous allocations when an allocation exceeds half the
chosen region size, which is minimum 1MB. By reducing the recovery
buffer size by 16 bytes we ensure that the recovery buffer is never
allocated as a humongous allocation.