The 216MB allocated should be the 'Heap' which is the memory the JVM gets to use. The 176MB is probably just the amount that is currently being used by the JVM.
Could you paste in the JVM config line from the jvm.config file in Jrun / bin / folder? that should say what the maximum allowable memory for the JVM is. It could be that the 216 is the maximum you have allowed for the JVM (which seams rather small) or it could be the amount that the JVM has currently allocated itself at that particular point in time. Depending on your config, JVM will resize the heap itself depending on its needs. That is called 'adaptive' sizing and is what I believe the default for JRun. Barry. On Mon, Feb 1, 2010 at 11:11 PM, Andrew Myers <am2...@gmail.com> wrote: > Hi Guys, > > Sorry this is turning into a long thread, but hopefully this will be > something that benefits others as well. > > I've got Fusion Reactor running now, and I can notice quite a few > spikes up to 100% CPU looking at the graph on the "System Metrics" > page. > > Also, memory usage is consistently up near the amount allocated. Eg. > if I hover over it is says 176MB used, 216MB allocated. > > That doesn't sound like much allocated to me. Exactly what memory > does this refer to? The memory allocated to the JVM? > > Regards, > Andrew. > > On 30 January 2010 03:13, charlie arehart <charlie_li...@carehart.org> > wrote: > > Great thread. I'll offer confirmation of a couple of points and share a > few > > more to help with solving CF server problems like Andrew's. > > > > First, I'll +1 Kai's observation that FR shouldn't cause any noticeable > > overhead. Beyond the Intergral folks' own declarations that it's low > > overhead, I can confirm the same from having worked with many, many shops > > using it in production. > > > > Now, you ask about the JDBC wrapper Andrew, and I can say that that too > has > > been enabled often and is so very helpful. (I blogged more about it at > > > http://www.carehart.org/blog/client/index.cfm/2008/7/22/fusionreactor_dataso > > urce_monitoring.) > > > > The only time I've seen FR get "in the way" was due to one specific > feature > > and then only in an extremely high load situation (hundreds of requests > per > > second), which can only happen when the JDBC wrapper feature is enabled. > > There's a feature in the JDBC Settings page (in FR) that's enabled by > > default, where it will cause FR to track and show the filename and line > > number of the captured call to the database (CFQUERY, CFSTOREDPROC, etc.) > > And to obtain that info, it has to do a stack trace. Under that VERY high > > load, then doing that on every query in every request was causing a > problem. > > But again that's a rare situation. And to be clear, it's only if you > enable > > the wrapping, and it can be turned off. > > > > By far the several dozen sites I've seen FR used in (with JDBC wrapping) > > have seen no negative and indeed only positive benefits from using it. > > > > That said, there have been other useful suggestions here of other things > one > > can look at in a trouble situation, and the first I'd recommend was the > > runtime logs (also called Jrun logs, as Barry noted). They're in the > > [coldfusion]/runtime/logs dir in server mode and in the [jrun]/logs in > > multiserver mode. These often offer valuable explanations for things that > > are amiss (though they can be large and/or have lots of info to wade > > through). With experience, one can often pinpoint the exact cause of poor > > performance, especially memory issues. There can even be surprises, like > > outofmemory due to "unable to create new native threads", which turns out > > NOT to be a problem of CF running out of heap space, but rather often > more > > an indication that the heap needs to be reduced! :-) > > > > That said, there are still times when there's no other recourse but to > > examine things at runtime, whether using tools like FR, SeeFusion, or the > > CF8/9 Enterprise Server Monitor. These enable you to see exactly what's > > running at any moment can be critical. You can see what requests are > > running, their URL, their input arguments (URL and form post), how long > > they've been running, and more. If you don't have those, then at least > the > > free CFSTAT tool can give very high-level metrics (how many requests are > > running, queued). JRun metrics can also provide some of that info and > more. > > > > But then there are also times when the nature of the problem is not so > much > > in what's happening "at any given moment" but instead what has happened > over > > time. For that situation, another valuable feature of FusionReactor is > its > > logs. Unlike SF or the CF Server Monitor, it logs every request (and > every > > query, if wrapping and query logging are enabled), and also logs every 5 > > seconds some great high-level measures like how many requests are running > at > > the moment, and have run in the past 5 seconds, the average response time > > for requests over that interval, how many queries are running and have > run > > in the past 5 seconds, their average response time over that interval, > how > > much CP and memory CF is using, and more. > > > > As someone who spends their day helping people with CF server problems > (as > > an independent consultant, carehart.org/consulting), I can say that 90% > of > > the time I can help them find the cause and solution to problems using > the > > tools and techniques above. Hope that's helpful. > > > > /charlie > > > > PS I will add that I have started to develop a couple of resources > focused > > specifically on CF server troubleshooting, to help gather and disperse > even > > more details on info like the above. I'll share more on them as they > become > > more developed. > > > > > >> -----Original Message----- > >> From: cfaussie@googlegroups.com [mailto:cfaus...@googlegroups.com] On > >> Behalf Of Kai Koenig > >> Sent: Wednesday, January 27, 2010 12:19 AM > >> To: cfaussie@googlegroups.com > >> Subject: Re: [cfaussie] Re: CF7 (and 8) High CPU usage on production > >> box > >> > >> We don't. But not necessarily due to performance issues with the > >> wrappers and FR (they're super lightweight) but because we use > >> other mean to monitor and watch the performance of the SQL Server. > >> > >> Cheers > >> Kai > > > > > > -- > > You received this message because you are subscribed to the Google Groups > "cfaussie" group. > > To post to this group, send email to cfaus...@googlegroups.com. > > To unsubscribe from this group, send email to > cfaussie+unsubscr...@googlegroups.com<cfaussie%2bunsubscr...@googlegroups.com> > . > > For more options, visit this group at > http://groups.google.com/group/cfaussie?hl=en. > > > > > > -- > You received this message because you are subscribed to the Google Groups > "cfaussie" group. > To post to this group, send email to cfaus...@googlegroups.com. > To unsubscribe from this group, send email to > cfaussie+unsubscr...@googlegroups.com<cfaussie%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/cfaussie?hl=en. > > -- You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to cfaus...@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
