There are two things to keep in mind here: 1. Heap size and minimum/start heap size vs. maximum heap size. I agree the best way to figure that out is to look at the jvm.config file.
>From my experience it's _generally_ a good idea to set min = max heap size right from the start, provided you have enough memory in the machine and aside a few other issues with that. 2. Adaptive sizing is something different. A JVM consists of different memory spaces internally, called generations. A modern JVM has the ability to adapt the size of the generations (young, old, permanent) according to the current requirements, garbage collection behaviour, heap settings etc. Again - from my experience with a lot of different systems that works average at best. Looking at Andrews original email; without seeing the actual jvm configuration it's hard to tell if it's configured appropriately. If your machine is really set to have 216 MB as the max heap size and you're having a site with decent traffic, I could see why you might be experiencing issues - it might just be not enough memory to avoid reasonable expensive cleanup (GCs). And Andrew, you're right - 216 MB wouldn't be much at all for CF. I'e got clients running CF 8 64 bit with 8 GB RAM and the heap gets a dedicated 6ish GB per machine. Those sites are high-volume sites with lots of traffic though. Some sort of matching my guess is that you're describing 100% CPU spikes and . Those _could_ be coming from the machine doing the mentioned above expensive GC way too often and/or too long because it doesn't have enough memory. But again - to tell more is somewhat outside the scope of a mailing list because one'd need to monitor the machine, have a look at the data etc. (at least I would to provide you with a proper analysis). It could well be that your CPU spikes come from something else happening on your system. Also - there are different GC patterns available - depending on what you'd like to achieve - high throughput or low pause. The first one is the default setting in CF 7 and 8 (not 100% sure if that has changed in 9). The latter is much better if you're happy to loose some of the overall GC throughput but want to avoid any lengthy GC pause. Cheers Kai On 1/02/2010, at 11:27 PM, Barry Chesterman wrote: > 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. > > 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. > > > > -- > 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. _________________________________________________ Kai Koenig - Ventego Creative Ltd ph: +64 4 476 6781 - mob: +64 21 928 365 / +61 450 132 117 web: http://www.ventego-creative.co.nz blog: http://www.bloginblack.de twitter: http://www.twitter.com/agentK -- 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.
