[
https://issues.apache.org/jira/browse/RATIS-2065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17875711#comment-17875711
]
Xinyu Tan commented on RATIS-2065:
----------------------------------
[~szetszwo], thanks a lot for reminding me! I have submmitted a PR!
> Avoid the out-of-heap memory OOM phenomenon of frequent creation and deletion
> of Raft group scenarios
> -----------------------------------------------------------------------------------------------------
>
> Key: RATIS-2065
> URL: https://issues.apache.org/jira/browse/RATIS-2065
> Project: Ratis
> Issue Type: Improvement
> Components: server
> Reporter: Xinyu Tan
> Assignee: Xinyu Tan
> Priority: Major
> Fix For: 3.1.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The current SegmentedRaftLogWorker will create one when it's created
> [DirectBuffer|https://github.com/apache/ratis/blob/master/ratis-server/src/main/java/org/apache/ratis/server/raftlog/segmented/SegmentedRaftLogWorker.java#L209],
> in the end will not take the initiative to release it. This requires the
> corresponding in-heap memory to be released by the GC before the
> corresponding off-heap memory can be freed.
> For frequent Raft Group creation and deletion scenarios, there may be plenty
> of in-heap memory that will not trigger GC, but the out-of-heap memory will
> be occupied by these deprecated DirectBuffers, and the out-of-heap memory OOM
> phenomenon will eventually occur.
> In IoTDB, We will
> [explicitly|https://github.com/apache/iotdb/blob/master/iotdb-core/datanode/src/main/java/org/apache/iotdb/db/utils/MmapUtil.java#L33]
> release outside the heap memory, thus avoiding a similar situation.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
