I can tell you that the maxobjects discard algorithm is pretty.. well.. ech...
That may explain the CPU overuse. I would start my bringing down the minutes, and see if that helps. I've been working through a leak with Brian G, but have been unable to reproduce it locally, so I have no idea what has happened there. He seems to have conquered it by using Java6u10. Mark On Sat, Sep 5, 2009 at 5:40 AM, Clint <[email protected]> wrote: > > Oh, I misunderstood you earlier. Yeah, we definitely had it off- all > three app functions disabled, and the app itself was closed, so it > wasn't connected to the runtime via Flex. > > Like I said, though, we experienced issues in both cases: Monitor on > and Monitor off. > > On Sep 4, 2:33 pm, Bob Silverberg <[email protected]> wrote: > > 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=ser... > > > > Cheers, > > Bob > > > > > > > > > > > > On Fri, Sep 4, 2009 at 3:15 PM, Clint<[email protected]> 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 <[email protected]> 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<[email protected]> 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: [email protected] > > >> >> > T:http://www.twitter.com/neurotic > > >> >> > W:www.compoundtheory.com > > > > >> -- > > >> Bob Silverbergwww.silverwareconsulting.com > > > > -- > > Bob Silverbergwww.silverwareconsulting.com > > > -- E: [email protected] T: http://www.twitter.com/neurotic W: www.compoundtheory.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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~----------~----~----~----~------~----~------~--~---
