Also:
-Xms is mininum (start) heap size, I usually do:
-Xms1024m -Xmx1024 (in your case)
There's also -XX:PermSize for the minimum (start) permanent generation size.
Note: I wouldn't tweak the perm size without having a good case for doing so,
i.e. something that points to that a different value for the permanent size
actually would have a positive impact. If you had JVM logs the Permanent
Generation running full and forcing full GCs for instance warrant that.
Cheers
Kai
On 2/02/2010, at 1:26 PM, Mark Mandel wrote:
> MaxPermSize set the PermGen size
> Xmx is the Maximum heap size
>
> Mark
>
> On Tue, Feb 2, 2010 at 11:22 AM, Andrew Myers <am2...@gmail.com> wrote:
> Hi Barry,
>
> I've just got hold of this
>
> java.args=-server -Djava.awt.headless=true -Xmx1024m
> -Dsun.io.useCanonCaches=false -XX:MaxPermSize=256m
> -Dcoldfusion.rootDir={application.home}/
> -Dcoldfusion.libPath={application.home}/lib -XX:+UseParallelGC
> -Dcoldfusion.classPath={application.home}/lib/updates,{application.home}/lib,{application.home}/gateway/lib/,{application.home}/wwwroot/WEB-INF/cfform/jars
>
> This is CF7 and the JVM is j2sdk1.4.2_18
>
> I'm pretty sure MaxPermSize sets the heap size, yes? Is there any
> point changing it?
>
> Andrew.
>
>
> On 1 February 2010 21:27, Barry Chesterman <barrychester...@gmail.com> 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.
> >
>
> --
> 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.
>
>
>
>
> --
> E: mark.man...@gmail.com
> T: http://www.twitter.com/neurotic
> W: www.compoundtheory.com
>
> Hands-on ColdFusion ORM Training @ cf.Objective() 2010
> www.ColdFusionOrmTraining.com/
>
> --
> 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.
