Driverhealth consumption memory (IDM 4.7 + edir 9.1.1)

[angelab1]

Hi

I started a new post here, in the previous, some of us shared a problem of memory consumption in a windows environment with IDM (https://forums.novell.com/showthread.php/508363-Memory-problem-with-eDirectory-9-1-IDM-on-Windows)
Now we have identified the cause, I will resume here:

windows environment with IDM 4.7 and eDir 9.1.1 with problems of memory consumption produced by the execution of the job of driverhealth: every time the job is executed, the consumption of memory increases (until 100%) and is not released after its completion.

same problem with IDM 4.7.1 or 4.6.2 with 9.1.1 or 9.1, in a fresh or updated from a previous version

Any Java expert? Any idea how to fix it?

the documentation says that the memory consumption should not be so high or increase:

https://www.netiq.com/documentation/identity-manager-47/driver_admin/data/bk1i57n.html


Regards

[aburgemeister]

It seems to me likely that this is an IDM bug more than a Java bug. Java
has managed memory well for decades, and a bug like this jumping in
suddenly in the middle of the 1.8 series just seems unlikely, but a new
bug finding its way into IDM seems more-probable (than the Java issue).

I think the best course is to get a fix from Micro Focus as they will have
access to the code that does this, unless they are saying it is a basic
Java issue.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.

[afuhrmann]

We also experienced this bug. The windows server crashed after 24h with just monitoring one single driver. Is there a timeframe when we can expect a solution for this major "Bug".

[joakim_ganse]

There are diffrent memory consumption issues.

Some were fixed i eDir 9.1.4

I am told the one I'm experiencig will be fixed in eDir 9.2 that will be out soon.

While I wait for that I have disabled the healt job since it is getting triggered by the job activity.

That worked well for me until I stared to use other jobs, now I need to restart eDir every second day as well. But got that scheduled so that works for a few weeks until I get the new version (hopefully)

[Alex McHugh]

We haven't seen that specific issue, but we did get a memory management fix for eDirectory on Windows. (fix is not included in eDir 9.1.4)

It has made a huge difference in reliability and performance at ALL of our customers.

Suggest you try and obtain that and test again, your issue might go away.

We have not seen any substantial pure memory leaks since applying that fix. 

[afuhrmann]

Thx for your quick responses. Where do I get your memory management fix?

[joakim_ganse]

You need to open a SR (Service Request) for it.

[Marcus Tornberg]

Hi!

We are also experiencing memory issues on Windows (eDir 9.1.4.1 and IDM 4.7.3.1). We have singled out that the workorder driver is consuming memory. We have an SR open, but no solution yet.

@Alex McHughdo you have a SR or patch reference I can use to try that patch? I have not received it yet. (didn't know it existed even!)

Best regards

Marcus

[Alex McHugh]

Our SR# was 101243968911 

The issue was in eDirectory in the memory allocation library.

Our remaining issue with redcent IDM/eDir versions is not a memory leak but rather a handle leak in certain situations. This may to be related to misconfigured SNMP on the server.

Regards, Alex

[sma2006]

I've got a patch from NetIQ to solve this issue.

This is a special version of file libtcmalloc_minimal.dll.

Please send me private email if you want it.

thx

Sylvain

[Marcus Tornberg]

Our issue also seems to be resolved with this patch.

Have a nice weekend all!

Best regards

Marcus

[cpedersen]

Please do not share “one-off” fixes that way, the best would be to have people open an SR and refer to the Bug to get the fix. That way MF will see how many people have the problem, and maybe be faster in releasing an public patch.