[NETCONF-256] excessive memory consumption when mounting devices Created: 11/Aug/16  Updated: 15/Mar/19  Resolved: 20/Oct/16

Status: Resolved
Project: netconf
Component/s: netconf
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Giles Heron Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: All


Attachments: Text File asr9000v.txt     Text File asr9k.txt    
Issue Links:
Blocks
is blocked by YANGTOOLS-660 SchemaContext - excessive memory cons... Resolved
External issue ID: 6391
Priority: Highest

 Description   

Running Beryllium-SR3 on Linux I'm finding that I need to increase the max Java heap beyond 2G to mount 2 different devices running the same software version (so the models overlap - but there are some different models due to hardware specifics).

Once I increased heap to 4G I was able to mount both devices, plus a third and fourth device running different software versions.

At any rate this seems like excessive memory usage. Can someone please look into it.

I can provide logs (too big to post here)



 Comments   
Comment by Jakub Morvay [ 15/Aug/16 ]

How many models does these two devices provide? Can you please add them here as an attachment?

Can you also provide devices schema context building parts from logs?

Comment by Giles Heron [ 15/Aug/16 ]

The devices each provide around 400 models, but most of them overlap.

Comment by Giles Heron [ 15/Aug/16 ]

Attachment asr9k.txt has been added with description: hello from asr9001

Comment by Giles Heron [ 15/Aug/16 ]

Attachment asr9000v.txt has been added with description: hello from ASR9000v

Comment by Giles Heron [ 15/Aug/16 ]

I can send you the whole log offline?

Comment by Jakub Morvay [ 16/Aug/16 ]

(In reply to Giles Heron from comment #5)
> I can send you the whole log offline?

Yeah, you can. Just write me an e-mail and we figure something out.

Comment by Giles Heron [ 22/Aug/16 ]

Hi Jakub - any update on this?

Comment by Jakub Morvay [ 25/Aug/16 ]

Hi Giles, I tried to look at log you sent me, but I haven't seen nothing suspicious.

I will try to simulate this with test-tool with 400 models..

Comment by Andrej Mak [ 20/Sep/16 ]

Cause of excessive memory consumption is in yangtools. I've already created a bug.
https://bugs.opendaylight.org/show_bug.cgi?id=6757

Comment by A H [ 18/Oct/16 ]

To better assess the impact of this bug and fix, could someone from your team please help us identify the following:
Severity: Could you elaborate on the severity of this bug? Is this a BLOCKER such that we cannot release Beryllium without it? Is there a workaround such that we can write a release note?
Testing: Could you also elaborate on the testing of this patch? How extensively has this patch been tested? Is it covered by any unit tests or system tests?
Impact: Does this fix impact any dependent projects?

Comment by Andrej Mak [ 19/Oct/16 ]

This issue has been resolved in master, Boron and Beryllium by fixing https://bugs.opendaylight.org/show_bug.cgi?id=6757

Comment by A H [ 19/Oct/16 ]

Has this bug been verified as fixed in the latest Beryllium SR4 Build 20161019?

Comment by Giles Heron [ 19/Oct/16 ]

I can test if you point me at the build

Comment by Giles Heron [ 19/Oct/16 ]

I can test if you point me at the build

Comment by A H [ 19/Oct/16 ]

(In reply to Giles Heron from comment #14)
> I can test if you point me at the build

https://nexus.opendaylight.org/content/repositories/autorelease-1542/org/opendaylight/integration/distribution-karaf/

Comment by Giles Heron [ 20/Oct/16 ]

still seeing GC overhead exceeded mounting a single XRv node with 2G of JAVA_MAX_MEM.

Comment by Andrej Mak [ 20/Oct/16 ]

There is still high memory usage during building of schema context, so it is needed to increase heap size. When context is build, memory usage should drop to normal values.

Generated at Wed Feb 07 20:14:33 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.