I agree with your last point, Kai. Good one. As for your contention about some shops being unable to dig into their code to deal with what may be many problems, I understand that too. But when I suggest that other things are often the root cause, I do mean to say that in nearly all my experiences helping people, it's not code (or some far-reaching approach) that needs to be corrected. It really is more typically other things (admin, config, unexpected/improper traffic, etc.)
So I do still stand by asserting that in a situation one needs to find the root cause, or at least rule out as many usual suspects as possible. Then, sure, if the smoking gun would be complicated to resolve, it may be time to consider treating the symptom rather than the cause. :-) /charlie > -----Original Message----- > From: cfaussie@googlegroups.com [mailto:cfaus...@googlegroups.com] On > Behalf Of Kai Koenig > Sent: Thursday, February 04, 2010 2:22 PM > To: cfaussie@googlegroups.com > Subject: Re: [cfaussie] Re: CF7 (and 8) High CPU usage on production > box > > 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 -- 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.
