Jonathan, about CFSTAT, just to be clear, it reports the same
info as the Perfmon stats you were seeking. That's all I was trying
to say, and that if they DO work, then the Perfmon stats should
work.
As for "java monitoring", well, don't confuse FusionReactor
and SeeFusion with jvm memory monitoring tools. That's a whole
different kettle of fish. These are indeed Java monitors, but
that's not obvious to us as CFers using them. The point is simply
that they make it crystal clear what requests are running, and help
you drill into them to know why they may not be running well.
I should have pointed to another introductory resource on
using FR (as a CFer), at
http://www.carehart.org/articles/#2008_6.
As for the "enterprise monitor", do you mean the CF 8 Server
monitor? . And as for it being expensive, do you mean that you have
to buy Enterprise to get it? Or by "eating your young" do you maybe
mean that it can be expensive in terms of resources? That's only if
you turn on the memory tracking, in my experience.I'll add that I
also have articles at my site that I've done as extensive
introductions to the CF8 monitor.
As for your heap size quesiton, I don't yet run 64 bit so
someone else may need to chime in, but I suspect that if you're
running CF in 32 mode you may be limited to the same 2gig memory
space (and therefore a heap of about 1.3-1.5gb).
But you ask if reducing the heap will make GC more
aggressive. I think this sort of conjecture sometimes is fruitless.
There are differences in JVMs (so what people say/know/read
regarding 1.4 may not apply to 1.6), and what GC agorithm is used
(and what the default is in different JVM versions), and so on.
Really, you need to test things. You can observe GC processing by
enabling GC logging.
Still, I'd argue you may be heading down a wrong rabbit hole.
What led you to jump from the problem you described to GC issues? I
know many articles/blogs point to that as the first thing to
investigate/tweak, but I don't agree. My approach (and
recommendation to my clients) always is to get the right diagnostic
info to tell you what's wrong, then go fix that.
In my experience, it's hardly ever code. Instead, it's nearly
always configuration, whether of CF, JRun, the JVM, the DB, the OS,
the web server, the network, etc. And honestly, it's often very
simple once you get the right diagnostics.
So what about my last question, about what the runtime out
log said before the last error? I have various things I might guess
it could be, from experience, but again lets let your system tell
us what's wrong.
... View more