If you go to the Server Monitor, you'll see three buttons at the top of the screen, one for each of:
Monitoring, Profiling, Memory Tracking If the option is currently off, the button will read "Start xxx", if it's currently on it will read "Stop xxx" Make sure that all of them are currently turned off. You can also do this via the admin api, using the stopMonitoring() method. More info is available here: http://livedocs.adobe.com/coldfusion/8/htmldocs/help.html?content=servermonitor_14.html Cheers, Bob On Fri, Sep 4, 2009 at 3:15 PM, Clint<clintmil...@gmail.com> wrote: > > How do you actually turn it off to completely disable it? We > experienced issues both with Profiling and Memory Tracking on and off, > but like you suggested, maybe the monitor was completely disabled? > > On Sep 3, 10:50 pm, Bob Silverberg <bob.silverb...@gmail.com> wrote: >> Were you perchance running the server monitor while these problems >> were occurring? I ran into a situation in which Transfer was having >> major problems when I had the server monitor running in the >> background, even though Profiling and Memory Tracking were turned off. >> I was led to believe prior to this that having just Monitoring on, >> without Profiling and Memory Tracking, would not impact the server's >> performance, but it did. As soon as I turned off all monitoring my >> problem went away. >> >> This may not apply to your situation, but if it does, try turning off >> the monitor entirely and see what happens. >> >> Cheers, >> Bob >> >> >> >> >> >> On Thu, Sep 3, 2009 at 11:28 PM, Clint<clintmil...@gmail.com> wrote: >> >> > I want to chime in and give some slightly tangential information about >> > this issue we ran into. (I work with "Z" on this product): >> >> > Because we originally thought that our application code was leaking >> > memory (and indeed, it may still be, and the memory profiling options >> > on ColdFusion 7 (JVM 1.4 series) are limited, to say the least, we >> > thought we would go ahead upgrade ColdFusion to the last version of >> > 8.0.1 running on JVM 1.6. (This is all running on 32-bit Windows >> > 2003). >> >> > Z made the necessary changes to our app and we upgraded our server to >> > CF8. The app ran but not as fast as expected- we expected very fast >> > performance based on many reports of heavy CFC-based apps. (We are >> > aware of the classloader bug in JVM 1.6_04 and experienced the issue >> > I'm describing on JVM 1.6_04, 1.6_11, and 1.6_16, and JVM 1.5_19). >> > Even more surprising than the diminished application performance, it >> > was never very long before the app server's CPU would be pegged at >> > 100%. A few times this happened we were able to peek under the hood >> > with Adobe's Server Monitor app. We saw at least one long running >> > thread during these times referencing Transfer's SoftReferenceHandler. >> >> > Upon further investigation, we realized that after the app started up, >> > under no load whatsoever the CPU usage would be 25%, 50%, 75%, or 100% >> > (notable b/c this is a 4 core machine). As best as I can tell, the >> > long running thread I observed was completely monopolizing the core on >> > which it was running, preventing the application from serving any >> > other requests. >> >> > After we rolled back to CF7 for current production, we provisioned a >> > Windows 2003 VM on Amazon EC2 and installed CF8 and our application. >> > We were not able to reproduce the problem that we described, and the >> > performance was more or less as we expected on 8 (reasonably fast >> > considering the minimal CPU power dedicated on the "smallest" EC2 >> > instance). >> >> > I don't know that any of this will help you, Mark, or anyone else >> > here, but it is an interesting observation and I want to provide as >> > much information as possible to aid in the resolution of this problem. >> >> > Thanks! >> >> > Clint >> >> >> > > Hi Everybody, >> >> >> > > We have an e-commerce website developed using Coldfusion 7, Model- >> >> > > Glue, Coldspring and Transfer. Over the past months we have struggled >> >> > > with what we thought was a "Memory Leak". We could see the jrun memory >> >> > > usage climb until it just became unresponsive (queue a bunch of >> >> > > requests and never serve them). We would then have to restart jrun and >> >> > > repeat the process over and over again. >> >> >> > > After months of trying to figure out what was going on we finally >> >> > > realized who the culprit was; the Transfer cache. >> >> >> > > Now, here's our original cache configuration: >> >> >> > > <objectCache> >> >> > > <defaultcache> >> >> > > <maxobjects value="60"/> >> >> > > <maxminutespersisted value="10" /> >> >> > > <accessedminutestimeout value="10"/> >> >> > > <scope type="instance" /> >> >> > > </defaultcache> >> >> >> > > <!-- SOME CLASSES WE DONT WANT TO CACHE --> >> >> > > <cache class="Users.Orders"> >> >> > > <scope type="none" /> >> >> > > </cache> >> >> > > .... >> >> > > </objectCache> >> >> >> > > It turns out leaving the cache on by default was killing us. Although >> >> > > performance was always great, under heavy load our site would >> >> > > sometimes have to go down every hour. >> >> >> > > After some experimenting we decided to turn the cache off by default >> >> > > and be very conservative on the objects we cached. Our latest >> >> > > transfer.xml looks something like this: >> >> >> > > <objectCache> >> >> > > <defaultcache> >> >> > > <scope type="none" /> >> >> > > </defaultcache> >> >> > > <cache class="Users.Customer"> >> >> > > <maxobjects value="60"/> >> >> > > <maxminutespersisted value="10" /> >> >> > > <accessedminutestimeout value="10"/> >> >> > > <scope type="instance" /> >> >> > > </cache> >> >> > > <cache class="Products.ProductType"> >> >> > > <maxobjects value="10"/> >> >> > > <maxminutespersisted value="30" /> >> >> > > <accessedminutestimeout value="10"/> >> >> > > <scope type="instance" /> >> >> > > </cache> >> >> > > ... >> >> > > </objectCache> >> >> >> > > I guess the main question I have is whether anyone here has had >> >> > > similar experiences or has any rule's of thumb when it comes to >> >> > > caching objects. We are still unsure on whether the behavior we were >> >> > > experiencing was an actual memory leak or just poor cache management. >> >> > > Any comments? >> >> >> > -- >> >> > E: mark.man...@gmail.com >> >> > T:http://www.twitter.com/neurotic >> >> > W:www.compoundtheory.com >> >> -- >> Bob Silverbergwww.silverwareconsulting.com > > > -- Bob Silverberg www.silverwareconsulting.com --~--~---------~--~----~------------~-------~--~----~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups "transfer-dev" group. To post to this group, send email to transfer-dev@googlegroups.com To unsubscribe from this group, send email to transfer-dev-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~----------~----~----~----~------~----~------~--~---
