Charlie and others, I agree with a lot of what you're saying. There are tons of potential issues that could be more obvious and in need to be fixed before even looking into GC details.
And it's particularly important to note that there is no overall "solution" - each setting and decision comes with a trade-off (GC strategy A vs B, throughput vs. low pause, generational memory here vs. gm there etc). There's a very interesting point in your reply though: > But more important, I would argue that in nearly all cases, GCs themselves > aren't the problem (or the solution). Far more often, the problem is simply > about what is using (and holding on to) memory, which is leading to high > memory use, which results in problems and error messages that may exhibit > themselves in reference to GCs, etc. You're totally right. I would even go further and argue that in no _cases_ GCs are the real issue. It's always the application or lack of memory or lack of another CPU or whatever and that manifests in memory hogging and clean- up issues. On the other hand though - in a lot of cases you'll find that it's not just a single file that causes those application issues. It might be years and years or unstructured coding. It might be an overall lack of common sense of the developer who had written 95% of that particular app and one can't just fix those issues. Well - yes, one maybe can - but management might not allow it, there might be no money/time to do it etc. And that's where I think GC and memory tuning can help a lot. Yes, it covers the underlying issue instead of solving it from the ground but it can help to make it less painful by optimising the situation you have and the constraints you have to work and live within. So, yes. GC tuning has its value and its point, but if you have a chance to solve the real issue, I would always suggest to do that first and then maybe use GC tuning to further fine-tune things. To provide a maybe controversy point of view as well - I find more and more that the default JVM settings in CF are far away from being "right". I'd much prefer the installer to ask a few questions (how many CPUs is CF using, how much mem do you have available, how much mem would you want to dedicate to CF, are you using a CFC-intensive framework etc) and then potentially come up with a better choice of GC/JVM settings. I feel there's a blog post on that that particular topic more than overdue ;-) Cheers Kai On 5/02/2010, at 4:32 AM, charlie arehart wrote: > Andrew, in addition to the other helpful replies to your question offered so > far, I'll add a bit of a contrarian perspective: I don't know that there's > generally much value in worrying about when/how garbage collection is > happening. I'll even say further that some focus too much on tweaking GC > algorithms and more. > > Yes, I realize that there are lots of blog entries out there about how one > way is better, or was "the solution" for them, etc. First, consider that you > have to know what JVM version that recommendation was written for (CF 6 and > 7 run on JVM 1.4.x and CF 8/9 run on 1.6.x). > > But more important, I would argue that in nearly all cases, GCs themselves > aren't the problem (or the solution). Far more often, the problem is simply > about what is using (and holding on to) memory, which is leading to high > memory use, which results in problems and error messages that may exhibit > themselves in reference to GCs, etc. > > As for what's using memory excessively, it may be a coding issue (for > instance, a query bringing back huge results), or it may be a configuration > issue (the CF Admin set to permit thousands of cached query results, which > code is causing to be used with large result sets), or it could be a traffic > issue (thousands of spiders/bots requesting pages and creating new sessions > on every request, where code in the application.cfm/.cfc might put large > amounts of data in session scope), and so on. > > The point is, generally we need to resolve the use of memory (and its not > being released to be garbage collected) rather than monitor/tweak the GC > mechanism itself. I don't deny there are SOME cases where maybe GC > tweaking/monitoring can make a difference. I'm just saying that in nearly > all of about 100 cases where I've helped with memory issues, the solution > was not in GC monitoring or tweaking. > > Intelligent folks may disagree on this, so I'm not quoting gospel truth. > Again, just offering another perspective. > > /charlie > > >> -----Original Message----- >> From: cfaussie@googlegroups.com [mailto:cfaus...@googlegroups.com] On >> Behalf Of Andrew Myers >> Sent: Wednesday, February 03, 2010 5:11 PM >> To: cfaussie@googlegroups.com >> Subject: Re: [cfaussie] Re: CF7 (and 8) High CPU usage on production >> box >> >> Thanks Mark. >> >> Is anyone able to please tell me how I can identify when garbage >> collection is happening? >> > > > -- > 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.
