Actually (was missing the m)
> -Xms1024m -Xmx1024m
....
Cheers
Kai
> 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.
_________________________________________________
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.
