RE: Reactor Performance was RE: [Reactor For CF] Been out of touch, but trying to get back

[Mike Brunt - Webapper Services, LLC]

As a quick explanation about garbage collection, objects are inspected to see if there are any references to them if there are not they are garbage collected and the memory is freed up.  So if the references to any objects are not being released effectively in an application they will hang around.  That is a vey basic explanation of why objects are not collected and memory is not freed up.    I think there is another thought point here, Jeff Lester mentioned he does NOT have similar issues (correct me if I am wrong Jeff) does Jeff also use the Blog Application?   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 Doug Hughes Sent: Friday, May 26, 2006 8:32 AM To: reactor@doughughes.net Subject: RE: Reactor Performance was RE: [Reactor For CF] Been out of touch, but trying to get back 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: reactor@doughughes.net 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: reactor@doughughes.net 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 -- reactor@doughughes.net -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/ -- Reactor for ColdFusion Mailing List -- reactor@doughughes.net -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/ -- Reactor for ColdFusion Mailing List -- reactor@doughughes.net -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/ -- Reactor for ColdFusion Mailing List -- reactor@doughughes.net -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/