Idempiere 2.1 is not releasing memory after rendering HTML reports

[Pedro Rozo]

Hi everyone

After some "Out of memory" errors with idempiere 2.1 running some reports, where have checked suggestion from different thread and we introduced some JVM parameters to fix them,  

 -Xms768m -Xmx1024m -XX:PermSize=256m -XX:MaxPermSize=512m

So far the reports are running now. 

But during the process we noticed that after running a report like this one, (Open Ítems -> Invoice Tax )where it was rendered as HTML .... idempiere is not releasing the memory (checked with the linux command : top . before and after running the report), it sounds like the garbage collector is not running or not releasing properly that huge memory used during the rendering.

Then, after running that report, is is extremely easy to have new "our of memory" errors, becauase that memory is not released properly... we tried to close the current borser session, also running a clear cache .. but still that memory is not released.

Any suggestions to manage this memory leak with reports, any idempiere option/JVM option to force this garbage collection/memory release properly ?

Regards

Pedro R  

[norber...@multimageweb.com]

hi,

can't answer right way, no solution, however i red this week around, and have in my browser some useful articles: 

http://docs.oracle.com/javase/7/docs/technotes/tools/share/jstat.html#gcutil_option (i like this help me understand what happening inside java...)

http://www.cubrid.org/blog/dev-platform/how-to-tune-java-garbage-collection/

https://engineering.linkedin.com/garbage-collection/garbage-collection-optimization-high-throughput-and-low-latency-java-applications

norbert

[Carlos Antonio Ruiz Gomez]

Pedro, the first thing is to isolate if really it is a memory leak and not a GC tuning issue, for that is useful to read the docs suggested by Norbert.

top or ps are not enough to know if there is a memory leak as the GC management of java is kind of "unpredictable" when not tuned.

To discover memory leaks I think you must do something like:
- check the memory consumption before the report (you can use jconsole, or third party tools like newrelic, or plumbr)
- launch the report
- force a garbage collection - although this is also "unpredictable" - in theory a GC cannot be forced - but most of the time I see it works
- wait a little
- check the memory again

If the memory leak is confirmed then the troubleshooting is taking a java heap dump and analyzing it - eclipse has a memory analyzer tool that helps with that task.

Regards,

Carlos Ruiz


On 06/11/15 a las 11:28, Pedro Rozo wrote:

Hi Norbert

Thanks for your feedback, though your articles sound really interesting I am not sure if they apply to my original question ....have you checked if after rendering HTML reports.in your linux environment .. Idempeire is releasing memory properly .... it does not matter  if take some time (default GC parameters) ....but just check with the linux command top: or ps, the amount of memory for the java process before renedering a report .... and some minutres after you render the report ... in our case still shour after the rendering, the memory consumption is just increased but not released.

I know some GC settings can change the time & frequency the memory is released, but still with the JVM defaults, after some minutes or hours Idempiere should release that memory to the operating system, right ?

I am wondering if someone else is having the same situation  (we were able to replicate that behavior en more that 3 instances of Idempiere (it does not release memory) .

Perhaps  Carlos, Hen Sin Low or any other developer with experience in the core classes,  can suggest us any additional settings of Idempiere about it, because currently it affects all the memory management .

Regards

Pedro R

--

[Pedro Rozo]

Hi Carlos

Thanks for answering, I agree that is the normal procedure for debug/tune new java code, but my question here is that potential memory leak  is currently happening with more than five different reports (from the current core ERP:report engine & default reports), they are not new  or part of new contributions ....all of them are default ERP reports that consumes memory and after rendering in HTML the memory is not released ...

So having in mind that is really easy to replicate the issue in any idempiere 2.1,  is that I am wondering if more people is having these issues/or applying any other config/recommendations before going to perform those JVM procedures.    Any additional thoughs, feedback from other people running big rHTML reports perhaps ?

Our environment is CentOS Linux with Idempiere 2.1 + Postgres 9.3

Regards

Pedro R.

[Raouf Mazouz]

Hi Pedro,

try with this option :

-Xms1024m -Xmx1024m -verbose:gc -XX:+UseParallelGC -XX:MaxGCPauseMillis=5000 -XX:+AggressiveHeap -XX:PermSize=256m -XX:MaxPermSize=256m -XX:NewRatio=8 -XX:-HeapDumpOnOutOfMemoryError -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps

Br,

Raouf

[Carlos Antonio Ruiz Gómez]

This thread is old, but to let community know that Hiep just implemented fixes for memory issues managing the HTML reports here:

https://idempiere.atlassian.net/browse/IDEMPIERE-3104

Regards,

Carlos Ruiz

[Ankit Bhavsar]

Hi All,

I did face Heap space error yesterday I guess someone might have run report before I accessed.

[Hiep Lq]

I guess it's time after Carlos run test to sure about issue.

Sent from my BlackBerry - the most secure mobile device

From:ankit....@knowarth.com Sent:July 19, 2016 12:30 To:idem...@googlegroups.com Reply-to:idem...@googlegroups.com Subject:Re: [idempiere] Re: Idempiere 2.1 is not releasing memory after rendering HTML reports

--
You received this message because you are subscribed to the Google Groups "iDempiere" group.
To unsubscribe from this group and stop receiving emails from it, send an email to idempiere+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/idempiere/eb8885a0-bd45-4b4a-a345-3ca2a165aee4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.