It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Follow this question
Question details

×42,787
×5,996

question asked: Apr 23 '14, 1:05 p.m.
question was seen: 3,474 times
last updated: Apr 23 '14, 4:26 p.m.

Related questions

FAQ - How this Forum works

How to do problem determination when heap analysis shows 88% of heap used

0
Kevin Ramer (4.5k●8●183●200) | asked Apr 23 '14, 1:05 p.m.
 Got a server crash (2nd in a week) after fairly stable operation.  Analyzed today's heap and found:


Usually I can root around in that tree to find an owning object  ( e.g. org/eclipse/birt/something ) but this one is baffling as I cannot pin this upon anything.


One answer

Most liked answers|Newest answers ↑|Oldest answers

0
permanent link
Benjamin Silverman (4.1k●6●10) | answered Apr 23 '14, 2:48 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi Kevin,

I'd suggest also capturing some javacore samples over a period of time while this problem is happening.  Application logs will sometimes clue you in as well.  I'd suggest capturing ISALite output along with the javacores and heap dump and creating a PMR so support can investigate further.
Comments
Kevin Ramer commented Apr 23 '14, 4:26 p.m.

My 107th favorite thing to do..   This particular RTC has been so given to dumping that it is often started with dumps disabled.  (https://jazz.net/forum/questions/108730/how-to-troubleshoot-birt-reports-that-consume-excessive-timecpu for example).   Right after we upgraded to 4.0.5 I put a hard limit on report execution time. 

For those I could definitely find a pattern; or at least find the object that owned the biggest heap segment.   The last two have totally different patterns than those caused by BIRT reports and each other.

Your answer

Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.