Re: Memory control
Re: Memory control
- Subject: Re: Memory control
- From: Pascal Robert <email@hidden>
- Date: Mon, 14 Mar 2011 09:41:31 -0400
Le 2011-03-14 à 08:49, Philippe Rabier a écrit :
> Don't forget you can also schedule your instances with WOMonitor.
>
> However, I know some "big" apps that are running several weeks without restart. So it's not a fatality…
Problem can be that the heap usage goes down when the GC do it job, but the Java process still take the same amount of memory pre-GC-cleanup. At my previous job, we had a SOAP Web service that sometimes would take up to 1.5 GB of RAM. When the GC did his job, heap usage went down to .6 GB (you can monitor this by JMX) but at the OS level, the process still take 1.5 GB of RAM. So yes, sometimes you have to restart your apps to reduce the amount of RAM used.
> There is also JProfiler that is good tool (but not free).
>
> And there is an interesting WOWODC'08 video about Shark (I hope Shark is still usable with java applications).
> http://www.wocommunity.org/webobjects_screencasts.html
>
> Philippe
>
> On 14 mars 2011, at 11:52, Q wrote:
>
>> Try using jvisualvm or a similar tool to get a heap dump of the JVM after it has been running for a while so you can see where the memory is actually being used.
>>
>> On 14/03/2011, at 6:36 PM, Gennady Kushnir wrote:
>>
>>> Hello again everybody.
>>> I still hope somebody would answer.
>>> I'va made GC logging with -XX:+PrintGCDetails and I see some
>>> interesting things happening.
>>> It seems like some uncollectable garbage is being accumulated in memory.
>>> Within the first hour heap usage goes up 35M and then within next 6
>>> hours falls back to that number after rare fullGC acts.
>>> After 8 hours that lower limit goes up to 40M, after 20 hours - to 45M
>>> and fullGC acts happen significantly more often.
>>> After 30 hours heap usage would not fall lower 50M and after 35 hours
>>> almost every GC is fullGC. Since 60 hour lowest heap usage is 55M.
>>> Finally at about 95 hours I get OutOfMemory error as the heap is
>>> limited by default to 64M.
>>>
>>> So my question is - what should I do now?
>>> Is it expected behavior for large WO application?
>>> Should I simply rise max heap limit to find memory amount that would be enough?
>>> Should I schedule WOMonitor to restart the App every night?
>>> Or such behavior should be considered as my error somewhere in code?
>>> So where should I look for memory leaks?
>>>
>>> 2011/3/3 Gennady Kushnir <email@hidden>:
>>>> Hello All!
>>>> I would raise this topic again. Thanks for all tips you have me.
>>>> Jprofiler is too commercial for me unfortunately. And VisualVM failed
>>>> to run on my deployment system (Xserve G4).
>>>> In fact even when run on my dev system, I could not actually figure
>>>> out how it could help me :(
>>>> I feel sad about I loosely know many aspects in Java technology. Could
>>>> you give me some links where to read about such things as "Eden",
>>>> "young generation" and "survivors" - I did not get these terms.
>>>>
>>>> And about those ec's that don't get garbage collected. After
>>>> eliminating all references to EO's outside components I still could
>>>> not get rid of that issue.
>>>> When debugging I've finally noticed inside a WOSession object an
>>>> NSMutableDictionary called _contextRecords, which holds hard
>>>> referenced on ALL previously used components. Even though I have
>>>> reduced pageCacheSize to 5 in an Application constructor.
>>>> And those components hold references to those ec's so they can't get
>>>> garbage collected...
>>>> Sad...
>>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden