All,

This has been an enlightening discussion and while I admit holes in my understanding, I appreciate the information disseminated to date.

And while I am sure this was not a sales pitch, I have spent some good time on the Webapper site and appreciate more fully their offerings. A very impressive group!


It seems like the major contributing factor to clearing up the original issue was disabling Explicit Full GC's.

Since CFMX 7 ships with this enabled, I wonder what the side-effects are of disabling Explicit Full GC's. Should this be done for new CFMX installs, regardless of the presence of this currently observed issue?


Thanks for the public discussion on this topic. I know there are other CF developers out there who would appreciate a better understanding of the Java Core we work on top of.

Dan Wilson



On 5/26/06, Doug Hughes <[EMAIL PROTECTED]> wrote:

Mike – As always:  Awesome.  I've been using a tool called Jprobe to watch what variables CF creates when using my blog.  I can essentially run one use case and see what's around when I'm done.  Based on this, I'm beginning to suspect that this is in the OO queries…. I think that some of the various objects (join, field, order, etc) used by the queries are not released when the query is added back into the resource pool.  I'm not sure, however, how this could create such a leak.  OO queries are where I'll be focusing a lot of my time this weekend with reactor dev.  Maybe I'll track it down?  We'll see.

 

Doug

 


From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Mike Brunt - Webapper Services, LLC
Sent: Friday, May 26, 2006 11:05 AM
To: [email protected]
Subject: RE: Reactor Performance was RE: [Reactor For CF] Been out of touch, but trying to get back

 

Just a quick update on what I found this morning.  Doug last restarted his CFMX instance here 05/25 21:47:47, the first Full GC ocurred 5.4 hours later (which is early morning?) and as with the previous behavior did reclaim a good amount of memory (around 220MB).  However, in the total time the system has been up there have been 56 Full GC's and as before the most recent ones reclaim virtually no memory.

 

As of 10 minutes ago there was 220MB of available memory which is reasonable.  I will be sending Doug some other suggestions as tweaks to the JVM arguments in a little while to see if we can control those Full GC's more effectively.  I will also have some observations about the New and Old memory segments.

 

Kind Regards - Mike Brunt

CTO and Lead Architect - Webapper Services LLC

Tel 562.243.6255

Web Site: http://www.webapper.com

Blog: http://www.webapper.net

Tools: http://www.seefusion.com

 

 


From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Brian Kotek
Sent: Thursday, May 25, 2006 2:44 PM
To: [email protected]
Subject: Re: Reactor Performance was RE: [Reactor For CF] Been out of touch, but trying to get back

Mike I'm afraid I can't add to the technical discussion becuase the innards of the JVM are way over my head. But I am learning a lot from hearing this back and forth and I wanted to thank you for stepping up and helping Doug work through this.

Thanks,

Brian

On 5/25/06, Mike Brunt - Webapper Services, LLC <[EMAIL PROTECTED]> wrote:

I thought I would add a bit to the subject line so that we know this is
about the performance review we are carrying out for Reactor at Doug's
place.  If you recall yesterday we observed the following as far as Full
Garbage Collections (Full GC's) on Doug's instance running Reactor:

"In 8.9 hours of uptime there were 786 Full GC's, that is one every 41
seconds the latest ones are taking 3.8 seconds"

Doug applied a change to the jvm.config file to disable Explicit Full GC's.
Explicit Full GC's are Full GC's called either by an application, a command
or a process such as RMI (Remote Method Invocation). After the change
applied by Doug there is a very noticeable change.

In the 4.08 hours since Doug started the instance with Explicit Full GC's
disabled there have been 19 Full GC's.  We can be fairly certain that these
Full GC's are being activated by the JVM itself.  19 is much better however
there is still evidence of them not being very effective, eventually and we
will watch that.  Here are some details:

The first Full GC occurred after 3.02 hours of uptime and was efficient (as
a comparison before these changes the first Full GC occurred at 0.012
seconds after restart and continued unabated).  This ([Full GC
515767K->256620K) tells us that before the Full GC 516MB of Ram was being
used by the JVM and after that reduced to 257MB.  At 3.6 hours after the
restart the Full GC's although still running are not reclaiming much if any
RAM.  So we have made some progress by disabling Explicit Full GC's and we
recommend that our clients do that unless there is a compelling not to do so
that they are aware of.

Doug, do you have any idea what your traffic level is like on this instance?

Kind Regards - Mike Brunt
CTO and Lead Architect - Webapper Services LLC
Tel 562.243.6255
Web Site: http://www.webapper.com
Blog: http://www.webapper.net
Tools: http://www.seefusion.com


-- Reactor for ColdFusion Mailing List -- [email protected] -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/

-- Reactor for ColdFusion Mailing List -- [email protected] -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/ -- Reactor for ColdFusion Mailing List -- [email protected] -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/



--
"Go for it, its later than you think" -- Reactor for ColdFusion Mailing List -- [email protected] -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/

Reply via email to