You guys rock with all kinds of answers, I'll definitely be trying them out
tomorrow when I have a better brain and before whirly.  Below is my
JVM.config file.

Also for others maybe following the thread I found this 1 of 4 article by
Charlie helpful, but then for Charlie I was trying to find the other parts
after I had determined that I was indeed getting the outofmemory errors in
the -out file
http://www.carehart.org/blog/client/index.cfm/2010/11/3/when_memory_problems_arent_what_they_seem_part_1

One thing I don't get about the -out files is why -out and -out1 are the
only current ones and then -out2 seems to be when the server first started
recording and then they only go to -out200 which was before I started
seeing this problem.  I see in your article I can make them bigger than
200kb, which I may have to do, but it seems weird they stop making at 200
and then I essentially only have the latest 400kb in two files

Ajas good point on the 10-day free trials, we have a copy of one or the
other that we purchased awhile back, but admittedly in our organization
Eric Jones was the main server maintenance guy, until he moved on.  He kept
track of those licenses and servers.  I've been debating which would be
longer, to find the license and learn the software or fix the problem :)

Finally, revisiting Charlie's idea to look at the last funky thing before
the server went down around 16:24 I do see this 2min earlier, and it is in
the app that utilizes Hibernate, so I'll definitely need to see if I have a
CFC incorrectly set up as an interface or abstract class java style in a
way that CF doesn't like and that potentially could be the root of this
deal.  Unfortunately, since my -out logs don't capture the last outage a
few days ago I can't compare, but maybe when I try to re-trigger the event
tomorrow I can get this same result.

12/06 16:22:28 Error [jrpp-4004] - Object instantiation exception.An
exception occurred while instantiating a Java object. The class must not be
an interface or an abstract class. Error: ''. The specific sequence of
files included or processed is:
F:\.........................\webroot\index.cfm, line: 883
12/06 16:22:44 Information [scheduler-1] - Session
8430f0f809b2ff4d892f6b78787f5d723575 ended on ip . Length: 2:00:01 Active
sessions: -1
12/06 16:22:52 Error [jrpp-4004] - Object instantiation exception.An
exception occurred while instantiating a Java object. The class must not be
an interface or an abstract class. Error: ''. The specific sequence of
files included or processed is: F:\.....................\webroot\index.cfm,
line: 883
12/06 16:22:56 Error [jrpp-4004] - Exception thrown by error-handling
template:
12/06 16:22:59 error ROOT CAUSE: java.lang.OutOfMemoryError: PermGen space

jvm.config file

#
# VM configuration
#
java.home=C:/Program Files/Java/jdk1.6.0_24/jre

# Arguments to VM
java.args=-server -Xmx512m -Dsun.io.useCanonCaches=false
-XX:MaxPermSize=192m -XX:+UseParallelGC -Xbatch
-Dcoldfusion.rootDir={application.home}/../
-Djava.security.policy={application.home}/../lib/coldfusion.policy
-Djava.security.auth.policy={application.home}/../lib/neo_jaas.policy
-Dcoldfusion.classPath={application.home}/../lib/updates,{application.home}/../lib,{application.home}/../gateway/lib/,{application.home}/../wwwroot/WEB-INF/cfform/jars,{application.home}/../wwwroot/WEB-INF/flex/jars
-Dcoldfusion.libPath={application.home}/../lib

#
# commas will be converted to platform specific separator and the result
will be passed
# as -Djava.ext.dirs= to the VM
java.ext.dirs={jre.home}/lib/ext

#
# where to find shared libraries
java.library.path={application.home}/../lib,{application.home}/../jintegra/bin,{application.home}/../jintegra/bin/international,{application.home}/../lib/oosdk/classes/win
system.path.first=false

#
# set the current working directory - useful for Windows to control
# the default search path used when loading DLLs since it comes
# before system directory, windows directory and PATH
java.user.dir={application.home}/../../lib

# JVM classpath
java.class.path={application.home}/servers/lib,{application.home}/../lib/macromedia_drivers.jar,{application.home}/lib/cfmx_mbean.jar,{application.home}/../lib/oosdk/classes,{application.home}/../lib/oosdk/lib,{application.home}/lib


On Tue, Dec 6, 2011 at 10:58 PM, Charlie Arehart <char...@carehart.org>wrote:

> On top of all that’s been said, I’d add this:
>
> Yes, it’s likely that you simply need to increase the maxpermsize.
> Sometimes just another 100-300 can be enough to solve the problem.
>
> But you also want to make sure that this is really the **first** error
> that puts CF into a bad state. It could be that something else precedes it
> and precipitates it.
>
> Look in in the [cf]\runtime\logs\, in its out log for this instance, at
> the time of your crash, and look back in that log (before the crash) to see
> if any other errors or unusual messages show up. If you see none for 1-20
> minutes before that permgen message, then that alone would seem to be the
> problem.
>
> As to how it could happen, you’re on the right track but not quite right
> in what you’ve concluded. The saving of class files is not quite connected
> as you think. That’s about compiling, where the permgen is about loading.
> CF loads classes into the template cache (and thereby the permgen, when
> they’re first requested--and are not in the cache already, or later when
> it’s no longer in the cache for any reason, including a restart. A class
> can be removed from the template cache also during the life of the server
> when the template cache becomes full and it needs to make room for a more
> newly requested one, by removing the least recently used one).
>
> And CF will obtain that class (to load when needed) either by compiling it
> from source on the fly, or by pulling it from that cfclasses directory (if
> you have enabled that “save class files” option in the Admin).
>
> So how does the permgen get stressed? Most often by excessive loading of
> templates into the template cache. Again, when it gets full, it removes the
> oldest to make room for new ones. How could it get full? Because the number
> of templates that need to be loaded (CFM files, CFCs,  and indeed a class
> is created for each METHOD in a CFC) exceeds its size. The default is 1024.
> That’s also not a hard cap. There is a soft cache on top of that.
>
> If you look in the cfclasses directory, see how many files are there. You
> might even sort it by date modified and see how many are recently edited.
> If that number is at or near 1024, it’s likely your app uses lots of files
> and therefore creates lots of classes, which can then cause this stress. If
> you increase the size of the template cache, beware that that cache is
> stored in the heap, so you may need to raise that, too. (Yes, loading
> things into the template cache then affects both the heap and the permgen,
> from my observation.)
>
>
> Does that make sense, does that help? You’re right, you don’t find much
> out there about it. Hope this is helpful. I may blog it once we have some
> back and forth. (I’ve hinted at this info in some entries, but not devoted
> one to it.)
>
> /charlie
>
>
>
> *From:* ad...@acfug.org [mailto:ad...@acfug.org] *On Behalf Of *Cheyenne
> Throckmorton
> *Sent:* Tuesday, December 06, 2011 10:09 PM
> *To:* discussion@acfug.org
> *Subject:* [ACFUG Discuss] PermGen CF Server Memory Errors
>
>
>
> One of our CF servers keeps needing to have the CF service rebooted on it
> in order to work and continue serving our sites 1-2x / week.  Fortunately
> we do have a web service on one of the other box that monitors this machine
> to let us know when it starts bugging out again.
>
>
>
> The error I am getting on the server has to do with an out of memory perm
> gen space issue, something that there is tons of stuff online about but
> nothing that I've been able to succinctly tell is a good idea to look
> toward resolving the issue.  Here are the errors we get before the service
> fails.
>
>
>
> javax.servlet.ServletException: ROOT CAUSE:  java.lang.OutOfMemoryError:
> PermGen space
>
>
>
> 12/06 16:24:46 Error [jrpp-3954] - PermGen space The specific sequence of
> files included or processed is:
> F:\...................\case-studies\ENDO-enduring-hot-seat-discussion\index.cfm''
>
> 12/06 16:24:46 error ROOT CAUSE: java.lang.OutOfMemoryError: PermGen space
>
>
>
> javax.servlet.ServletException: ROOT CAUSE: java.lang.OutOfMemoryError:
> PermGen space
>
>
>
> Server: Windows Server 2008 R2 64bit
>
> ColdFusion  9,0,1,274733 Standard
>
> Java Version:  1.6.0_24
>
> RAM 8GB
>
>
>
> JVM Arguments
>
> -server -Dsun.io.useCanonCaches=false -XX:MaxPermSize=192m
> -XX:+UseParallelGC -Xbatch -Dcoldfusion.rootDir={application.home}/../
> -Dcoldfusion.libPath={application.home}/../lib
>
> Despite my attendance of multiple Charlie lectures and/or because of such
> attendance I certainly do not consider myself an expert in the memory
> underpinnings of CF.  What I do believe is happening through some research
> and late night testing is that essentially the server stores information
> (in think in cfclasses) that is essentially compiled java code.  It does
> this to speed the delivery of data generated by CF in a caching like
> mechanism.
>
>
>
> There is a checkmark in the settings that says "Save Class Files" which I
> suspect would solve the problem if indeed this area is getting overflowed
> and not properly Garbage Collected (if GC even runs in PermGen).  However,
> unchecking that is not recommended for a production machine, and it would
> obviously slow down all of the sites.  Similarly I've seen posts that say
> to just increase the MaxPermSize, but I find many posts after those saying
> that is not solve and just delaying the problem.  I'd rather solve the
> problem.
>
>
>
> Additionally, when observing the websites when it is acting up we get a
> lot of totally blank pages along with 200 OK http response codes.  I have
> also gotten partial pages at times, but that all leads me to some sort of
> partial template loading until the permgen runs out of memory.
>
>
>
> Finally, I don't know that it is a 100% deal, but we have launched a new
> application on this server that makes use of the new ORM Hibernate
> functionality.  This happened right around the same time we started
> observing these issues.  This was my first shot at ORM within CF and I know
> I need to go back and re-look at how I have the lazy-loading set up.  I
> have a feeling that it can definitely be tuned better and that it's
> possible this type of code may make heavy use of the permgen space with
> dynamically loading data in the way that it works.  This heavy banging in
> the permgen along with an untuned JVM may be the combo that is causing our
> problems, or maybe I'm way off.  Figured I'd throw it out there to group to
> see what thoughts and solutions might be out there beyond my teams
> continued googling of words like "permgen", "coldfusion", "hibernate",
> "orm" and "arehart" :)
>
>
>
> - Cheyenne Throckmorton
>
>
>
> P.S. Looking forward to seeing folks at Whirlyball tomorrow night.
>
>
> --
> Cheyenne Throckmorton - Atlanta, GA
> Blog      : www.CheyenneJack.com
> Twitter   : @cheyennejack
> Founder : www.AtlantaUserGroups.com
>                www.TheTallStreetJournal.com
>                www.MohawksRock.com
>
> -------------------------------------------------------------
> To unsubscribe from this list, manage your profile @
> http://www.acfug.org?fa=login.edituserform
>
> For more info, see http://www.acfug.org/mailinglists
> Archive @ http://www.mail-archive.com/discussion%40acfug.org/
> List hosted by FusionLink <http://www.fusionlink.com>
> -------------------------------------------------------------
>



-- 
Cheyenne Throckmorton - Atlanta, GA
Blog      : www.CheyenneJack.com
Twitter   : @cheyennejack
Founder : www.AtlantaUserGroups.com
               www.TheTallStreetJournal.com
               www.MohawksRock.com

Reply via email to