ColdFusion 9 Server Memory Issues
Steve Onnis
Has anyone had any issues with CF9 and memory? I have this strange problem where it does not seem to be giving it enough. Looking at the windows task mananger the jrun.exe process seems to not want to go over 300,000-400,000 K
Zac Spitzer
> --
> You received this message because you are subscribed to the Google Groups
> "cfaussie" group.
> To post to this group, send email to cfau...@googlegroups.com.
> To unsubscribe from this group, send email to
> cfaussie+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/cfaussie?hl=en.
>
--
Zac Spitzer
Solution Architect / Director
Ennoble Consultancy Australia
http://www.ennoble.com.au
http://zacster.blogspot.com
+61 405 847 168
Steve Onnis
the simultaneous requests setting and it was still set to 10. Surely not
enough for a production server :)
Carl
How much RAM is installed on your Windows server? Is Windows & CF 32
or 64 bit?
Less than 500Mb RAM used by Jrun on a server installed with 4Gb RAM
would seem reasonable to me.
Regards, Carl.
Steve Onnis
Hi Steve,
Regards, Carl.
--
Sean Corfield
> 32 Bit WIN2003 4GB ram, 1GB assigned to CF as thats all i can give it
Yeah, on 32-bit Windows, 1.4GB is the most you can give it. I pretty
much never run CF in production with less than a 2GB heap (usually 2GB
min, 3GB max) but of course I don't use Windows in production. On
64-bit servers you can go higher but if you go beyond 4GB, you need to
be very careful about the GC configuration you use... Even tho' it's
only experimental in Java 6, if you use a large heap, the G1 collector
is worth trying (but, as always, it's all about load testing / real
live load and constantly tuning the GC configuration to get the best
overall performance).
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/
"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)
Carl
than half of what you allocated? Would seem to me not enough memory is
been taken or it simply does not need to grow memory wise up to the
maximum. Perhaps this is the issue - it is growing to less than half
of 1Gb and your getting out of memory errors?
On 32 bit you are close to right in saying you can only set the limit
to 1Gb total. In reality it is a bit more 1.3 - 1.4Gb depending on
some variables.
Cheers, Carl.
Carl
I notice Java 7 is due for release at end of July. With java 7 you get
the released version of UseG1GC garbage collector - rather than
experimental option in java 6.
Cheers, Carl.
>
> Yeah, on 32-bit Windows, 1.4GB is the most you can give it. I pretty
> much never run CF in production with less than a 2GB heap (usually 2GB
> min, 3GB max) but of course I don't use Windows in production. On
> 64-bit servers you can go higher but if you go beyond 4GB, you need to
> be very careful about the GC configuration you use... Even tho' it's
> only experimental in Java 6, if you use a large heap, the G1 collector
> is worth trying (but, as always, it's all about load testing / real
> live load and constantly tuning the GC configuration to get the best
> overall performance).
> --
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View --http://corfield.org/
> World Singles, LLC. --http://worldsingles.com/
Sean Corfield
> I notice Java 7 is due for release at end of July. With java 7 you get
> the released version of UseG1GC garbage collector - rather than
> experimental option in java 6.
Yup. but I don't know how quickly (or even if) Adobe will certify
ColdFusion on Java 7...
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/
Kai Koenig
Sean Corfield
> FWIW - tried the G1 collector on Java 6 (_16 release iirc) for a large deployment on Win64/CF 8 for a while and had regular fatal JVM crashes. I'm pretty sure it has improved in later versions, but everyone be aware, that the G1 collector in Java 6 is _really_ experimental and it's not just a label Oracle sticked on to it :)
It was only introduced in _14 I believe and most folks says it was
pretty unstable up to about _20. I've seen good reports of folks using
it with _22 and up.
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/
Carl
On Jul 14, 11:40 am, Sean Corfield <seancorfi...@gmail.com> wrote:
> On Wed, Jul 13, 2011 at 4:40 AM, Kai Koenig <k...@koeni.de> wrote:
> > FWIW - tried the G1 collector on Java 6 (_16 release iirc) for a large deployment on Win64/CF 8 for a while and had regular fatal JVM crashes. I'm pretty sure it has improved in later versions, but everyone be aware, that the G1 collector in Java 6 is _really_ experimental and it's not just a label Oracle sticked on to it :)
>
> It was only introduced in _14 I believe and most folks says it was
> pretty unstable up to about _20. I've seen good reports of folks using
> it with _22 and up.
> --
version 21.0-b17. So far am impressed, particularly using G1. Tho Java
7 being preview it has not been near more vital / loaded CF
environments – so early days.
For those interested readers a very brief recap on garbage collection.
The Java heap is divided into 3 regions: young, tenured/old, and perm.
You may also know that young is further divided into eden and two
survivor spaces. A minor garbage collection finds all live objects and
puts them to one of the survivor spaces. Longer survived objects will
eventually move into tenured/old space. Some special objects land in
Perm.
From what I have gathered the G1 collector memory is divided into
multiple regions. Each of these regions will participate in a
generation. Some will be young, some to survivor, and others to old.
The collector is parallelized (multi-threaded) and will work
concurrently with your application (low pause). The minor collection
is similar to as current. There is a change to collection of regions
that are tenured/old space, there will be no separate collector.
Regards, Carl.