Much thanks to everyone who's responded to my posting. This community is
bar-none the best out there! Tweaking the JVM based on your suggestions has
made a world of difference. So far, my CF server has been running without
interruption for 1 day, 14 hours, and 22 minutes, and things seem to be
On Thursday 29 May 2008, Dan Crouch wrote:
We have a similar server setup on one of our servers. We picked up a copy
of SeeFusion and that really helped us track down some slow running pages
and queries, and other issues we werent even really aware of.
It's either that or an upgrade to CF8,
I don't think Enterprise will help you. If you have unstable
applications, you have unstable applications. Enterprise would let
you cluster multiple servers together, which might let you reduce
utilization per instance and potentially eliminate request timeouts
from CPU concurrency, but it's not
Actually with the small but growing load you have (small compared to
what our servers get) you may be getting to the point where you need
to do some JVM tuning.
What version JVM are you running and please post the java.args line
from the jvm.config file. I can offer plenty of tuning help.
Michael,
The level of traffic and usage you describe should be able to be handled
easily by a standard server (just ignore Adobe's marketing speak). The
question on upgrading is really about why you are experiencing difficulty
and what you expect to get out of enterprise. If you have a capacity
Thanks Wil,
I have actually been doing a fair amount of tuning the JVM. I'll definitely
read your article, but in the meanwhile, here's my jvm.config file. Let me know
if it seems totally wrong:
#
# VM configuration
#
# Where to find JVM, if {java.home}/jre exists then that JVM is used
# if
Michael,
So far pretty good. Most people I talk to about this haven't even
heard about tuning their JVM. My article is not complete yet and your
past the parts that I have posted.
So here are a few items for your java.args line. Your setting
maxpermsize and permsize. Good, but make
Michael,
These args are pretty close to what I use on several CF7 standard servers. I
don't see anything that jumps out at me. I wonder where you got the idea
that Jrun is only using 350 megs of memory however. The args below should
put it close to 1200 megs (1.2 gigs). What are you using to
Glad to hear I'm not totally off base with my settings. My server has 4 GB
physical memory. One thing I'm unsure about: you recommend using
'-XX:+UseParallelGC' for garbage collection. I've read a few articles that
recommended '-XX:+UseConcMarkSweepGC' (which is what I'm using now). Why do
Parallel GC is a different GC algorithm that works best with multi-
processors and large (Gb or greater) JVM heaps. We use parallel GC on
our servers with zero issues and we're pushing darn near a million
page views per day per server.
Those switches control the time interval between GC
Hi Mark,
To clarify about the JRUN memory usage: I'm looking in the Task Manager under
the Processes tab. When I sort on the 'Mem Usage' column, jrun.exe is almost
always at the top of the list, with at least 350 MB of memory being used at any
time. I'm also running FusionReactor to monitor
Hi Mark,
To clarify about the JRUN memory usage: I'm looking in the Task Manager under
the Processes tab. When I sort on the 'Mem Usage' column, jrun.exe is almost
always at the top of the list, with at least 350 MB of memory being used at any
time. I'm also running FusionReactor to monitor
We have a similar server setup on one of our servers. We picked up a copy of
SeeFusion and that really helped us track down some slow running pages and
queries, and other issues we werent even really aware of.
Dan
~|
Adobe®
Have you tried making the perm size bigger again? With lots of apps,
especially if any of them are using frameworks, you'll be using the perm gen
pretty heavily. If your app is freezing with plenty of headroom left in the
heap, perm gen is certainly a suspect.
Jaime
-Original Message-
We use both of these GC's under different circumstances. Concurrent mark
sweep GC is useful in that it is a little less heavy handed (using a 2 step
recovery
process that ties to young GC), but either of these GC's will work.
Your description of your memory leak problem sounds very much like
Yes, for a 1024 MB heap, the perm size is probably too small (it
depends on your code, primarily). The perm size needs to be
proportionately increased with the heap; try doubling it to 256 MB.
On Fri, May 30, 2008 at 6:49 AM, Jaime Metcher
[EMAIL PROTECTED] wrote:
Have you tried making the perm
16 matches
Mail list logo
