[MAGNOLIA-9056] Memory leak when re-registering module Created: 10/Aug/23  Updated: 02/Feb/24

Status: Selected
Project: Magnolia
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Neutral
Reporter: Michael Duerig Assignee: Oanh Thai Hoang
Resolution: Unresolved Votes: 0
Labels: dx-core-6.3
Remaining Estimate: Not Specified
Time Spent: 2d 4.5h
Original Estimate: Not Specified

Attachments: PNG File img-2.png     PNG File img-3.png     PNG File img.png     PNG File output-after-merge.png     PNG File threads-example.png     Text File threads_report-6-12-2.txt     Text File threads_report-6-12-after-2.txt     Text File threads_report-6.2-11-12-after-1.txt     Text File threads_report-6.2-11-12-before-1.txt    
Issue Links:
Relates
relates to MAGNOLIA-9051 Improve cache performance on public i... Open
relates to MAGNOLIA-9176 Apply central threadpool to DelayedEx... Closed
dependency
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Documentation update required:
Yes
Date of First Response:
Epic Link: Throughput improvements
Work Started:
Approved:
Yes

 Description   

According to UZH re-registering modules leads to leaked memory.

  • Timebox an attempt to reproduce this on a vanilla dx-core.
  • Reach out to UZH if we don't succeed in reproducing the problem
    • What are the symptoms?
    • Error messages, logs?
    • What module configuration change for this to show up?


 Comments   
Comment by Oanh Thai Hoang [ 11/Dec/23 ]

Here is a summary report about improvement of creating hundred of threads in public instance when publishing config.

 

Step to reproduce:

For 6.2 with dx-core-demo-webapp

  • Execute a groovy script to clone 100 site from travel site.
import info.magnolia.context.MgnlContext;
import javax.jcr.Node;
import javax.jcr.RepositoryException;
import javax.jcr.Session;
import javax.jcr.Workspace;


public class Test {
    public static void main(String[] args) {
        try {
            Session session = MgnlContext.getSystemContext().getJCRSession("config");
            Node node = session.getNode("/modules/multisite/config/sites/travel");
            for(int i= 0; i< 100; i++){
                String newPath = "/modules/multisite/config/sites/test"+i;
                Workspace workspace =  node.getSession().getWorkspace();
                workspace.copy(node.getPath(), newPath);
            }
        } catch (RepositoryException e) {
            e.printStackTrace();
        }
    }
} 
  • Setting /modules/advanced-cache/config@createseparatecachesforeachsite to true.
  • Execute publish include subnodes on ** /modules in Configuration app 2 or 3 times
  • Observe Threads chart in JProfile of public instance 
  • See threads increase significantly when publishing config 2 times
  • See thread dump: threads_report-6.2-11-12-before-1.txt. ~ 1000 threads

 

After applying central threadpool to DelayedExecutor MAGNOLIA-9176. Number of threads is reduced significantly. See threads_report-6.2-11-12-after-1.txt. ~ 150 threads

 

Note: This issue can't reproduce in 6.3 because DelayedExecutor in 6.3 has been changed and don't use ClockDaemon since MAGNOLIA-8660 . So there are not much change regarding number of threads before and after MAGNOLIA-9176.

See before threads_report-6-12-2.txt, after threads_report-6-12-after-2.txt. In my env, the number of thread is around 130~250. HEAP is also fine, HEAP is released and only around ~500mb

Additionally, for 6.3 site is isolated from /config, only accept yaml via site registry. So you have to create yaml file instead. Therefore no real observation in /config/site in public instance can cause restart advance cache multiple time like 6.2

Comment by Michael Duerig [ 12/Dec/23 ]

oanh.thai , I suggest that we reach out to UZH again once MAGNOLIA-9176 is released and ask them to test. If there's nothing more coming back from them we can resolve this ticket as fixed.

Comment by Oanh Thai Hoang [ 02/Feb/24 ]

After MAGNOLIA-9176 merged. The number of threads haven't increased significantly when publishing includes subnodes 2 times  /modules.

 

 

Generated at Mon Feb 12 04:38:12 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.