-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
High Memory Pressure In RestElasticSearchClient #4684
Comments
criminosis
added a commit
to criminosis/janusgraph
that referenced
this issue
Sep 26, 2024
9 tasks
criminosis
added a commit
to criminosis/janusgraph
that referenced
this issue
Sep 26, 2024
Closes JanusGraph#4684 Signed-off-by: Allan Clements <[email protected]>
criminosis
added a commit
to criminosis/janusgraph
that referenced
this issue
Sep 27, 2024
Closes JanusGraph#4684 Signed-off-by: Allan Clements <[email protected]>
criminosis
added a commit
to criminosis/janusgraph
that referenced
this issue
Sep 27, 2024
Closes JanusGraph#4684 Signed-off-by: Allan Clements <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the feature:
In RestElasticSearchClient there are a few places that can cause a high amount of memory pressure unnecessarily.
ByteArrayOutputStream
grows its underlyingbyte []
. These may then be released as the array grows, but then another allocation, usually 2x the previous one, is done which may itself be transitory. However the final step causes a copy of the final state of thebyte[]
within theByteArrayOutputStream
, which can be avoided.As a reminder the individual elements of each mutation batch can reach 100MB by default. The current client logic will split up each element into chunks so that they're below that limit, but a chunk of 1 is valid. So the copying here may reach non-trivial amounts, especially against concurrent client requests. So anything that can be done to release memory around these mutations as soon as possible maximizes the space JanusGraph can work with if the garbage collector starts getting desperate.
For what it's worth I've had a few OOM's occur in around the present
writeTo
logic:Describe a specific use case for the feature:
[If possible add a description of the specific use case.]
The text was updated successfully, but these errors were encountered: