You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Marcel Reutegger (Jira)" <ji...@apache.org> on 2023/06/01 15:20:00 UTC

[jira] [Commented] (OAK-10147) Many move operations may consume a lot of memory

    [ https://issues.apache.org/jira/browse/OAK-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728395#comment-17728395 ] 

Marcel Reutegger commented on OAK-10147:
----------------------------------------

During a discussions with [~stefanegli], [~daim], [~corderob] and [~ankitaagar] the suggestions was made to try to get rid of {{Move.destParent}} to reduce memory usage. With only the source and destination path left in a Move, memory usage will be drastically lower even when a MutableTree still references many pending Move operations.

The PR https://github.com/apache/jackrabbit-oak/pull/962 is an implementation of this idea. The current implementation is retained and can be enabled again either with a system property {{oak.classicMove}} or feature toggle {{OAK-10147}}.

I'd still like to spend a bit more time and add tests. I already discovered an issue in the current implementation (ClassicMoveTest#moveMoved()), which works fine on the new implementation. Either disable feature flag in ClassicMoveTest to run on the new implementation or run RootTest in oak-it, which has the same test.

> Many move operations may consume a lot of memory
> ------------------------------------------------
>
>                 Key: OAK-10147
>                 URL: https://issues.apache.org/jira/browse/OAK-10147
>             Project: Jackrabbit Oak
>          Issue Type: Task
>          Components: core
>            Reporter: Julian Reschke
>            Assignee: Marcel Reutegger
>            Priority: Major
>
> We have encountered an issue where a component did a huge number of move operations in transient space, and oak-core's "MutableRoot" class consumed ~800 MB for ca 3000 move operations. This seems to be a lot.
> We should:
> 1. Write a test / benchmark that reproduces the issue
> 2. Check whether it's specific to a certain store implemention
> 3. See whether the memory footprint can be reduced



--
This message was sent by Atlassian Jira
(v8.20.10#820010)