It turns out it was probably an explicit garbage collection call from one of the applications. As soon as I disabled the ability to explicitly call a GC (just let the JVM manage its own memory) the GC dropped to once an hour on an idle server.
Much better. thanks, Chris Norloff ---------- Original Message ---------------------------------- From: "Robertson-Ravo, Neil (RX)" <[EMAIL PROTECTED]> Reply-To: [email protected] Date: Wed, 18 May 2005 14:50:34 +0100 >When was the last time you patched? There were lots ones recently. > >Only other thing I could suggest at present is check the DB for unusual >activity....table locks etc. > >-----Original Message----- >From: Chris Norloff [mailto:[EMAIL PROTECTED] >Sent: 18 May 2005 14:52 >To: CF-Talk >Subject: RE: CFMX GC every 60 sec.? > >CFMX 6.1 with updater, in server mode, on Solaris 8. Have added a couple hot >fixes that apply to us. Using Apache(IBM HTTPD Server) and Oracle database. > >thanks, >Chris > >---------- Original Message ---------------------------------- >From: "Robertson-Ravo, Neil (RX)" <[EMAIL PROTECTED]> >Reply-To: [email protected] >Date: Wed, 18 May 2005 14:13:57 +0100 > >>Is this MX 6.1? Are you on SQL Server? IIS? >> >>Is the CF Server fully patched? >> >>N >> >> >> >> >>-----Original Message----- >>From: Chris Norloff [mailto:[EMAIL PROTECTED] >>Sent: 18 May 2005 14:11 >>To: CF-Talk >>Subject: RE: CFMX GC every 60 sec.? >> >>Thanks. This server has 1.5GB of memory, so I can set the heap larger as >>needed. The funny thing is that tools keep showing plenty of memory >>available ( % of Free Allocated Memory: 80-98%), but the Full Garbage >>Collection happens so often it just seems wrong. >> >>And the JVM allocates more memory where it's not needed (PSOldGen) and >>allocates less memory where it is needed (PSYoungGen). >> >>I'm going through a number of articles and blogs looking for info, and was >>hoping someone here could put their finger on the answer. >> >>The ( -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC >>-XX:+PrintGCDetails -Xms256m ) are indeed just for debugging. This is a >test >>server and we're trying to tune it for the applications. We had some hangs >>and crashes on the Production server with OutOfMemory errors. >> >>many thanks, >>Chris >> >>---------- Original Message ---------------------------------- >>From: "Robertson-Ravo, Neil (RX)" <[EMAIL PROTECTED]> >>Reply-To: [email protected] >>Date: Wed, 18 May 2005 13:50:45 +0100 >> >>>Well from what you state - it would seem the case that your app is using >>>more than you have allocated it hence purge via GC to clear the queue. >>> >>>What are your server specs? >>> >>>I would also remove XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC >>>-XX:+PrintGCDetails -Xms256m. I know they are probably for debugging but >>>they will have a detrimental effect on performance. >>> >>> >>> >>> >>>-----Original Message----- >>>From: Chris Norloff [mailto:[EMAIL PROTECTED] >>>Sent: 18 May 2005 13:27 >>>To: CF-Talk >>>Subject: CFMX GC every 60 sec.? >>> >>>Is it right for Garbage Collection to run every 60 sec., as regular as >>>clockwork? >>> >>>(CFMX 6.1 server, with updater, Solaris 8. JVM settings: -server >>>-Dsun.io.useCanonCaches=false -XX:MaxPermSize=256m -XX:+UseParallelGC >>>-Djavax.xml.parsers.SAXParserFactory=com.macromedia.crimson.jaxp.SAXParser >F >>a >>>ctoryImpl >>>-Djavax.xml.parsers.DocumentBuilderFactory=com.macromedia.crimson.jaxp.Doc >u >>m >>>entBuilderFactoryImpl -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC >>>-XX:+PrintGCDetails -Xms256m -Xmx768m) >>> >>>I'm trying to decide if what I'm seeing is right: >>> >>>- first unloaded classes after running for 13 min. >>>- PSPermGen getting to 98% but not increasing size to what's available >>>(MaxPermSize=256m) >>>- 'from space' in PSYoungGen regularly filling, appears to be causing the >>>GC. >>>- GC runs every 60 sec. >>>- PSOldGen gets the most space of the heap, but 'from space' in PSYoungGen >>>is what *needs* the space. >>>- NOTE: this is with the server idle. Now I need to see it under load. >>> >>>thanks, >>>Chris Norloff >>> >>>---------------------------------------------- >>>Heap >>> PSYoungGen total 87168K, used 84000K [0xb9000000, 0xbe550000, >>>0xc9000000) >>> eden space 3008K, 0% used [0xb9000000,0xb9000000,0xb92f0000) >>> from space 84160K, 99% used [0xb92f0000,0xbe4f8000,0xbe520000) >>> to space 192K, 0% used [0xbe520000,0xbe520000,0xbe550000) >>> PSOldGen total 174784K, used 6449K [0xc9000000, 0xd3ab0000, >>>0xe9000000) >>> object space 174784K, 3% used [0xc9000000,0xc964c5a8,0xd3ab0000) >>> PSPermGen total 16640K, used 16453K [0xe9000000, 0xea040000, >>>0xf9000000) >>> object space 16640K, 98% used [0xe9000000,0xea011630,0xea040000) >>>15399.411: [Full GC 90449K->6460K(261952K), 0.6580179 secs] >>> Heap after GC invocations=510: >>>------------------------------------------------------------ >>>- just like clockwork. this is obviously the established pattern. >>> >>> PSYoungGen total 87232K, used 84136K [0xb9000000, 0xbe550000, >>>0xc9000000) >>> eden space 3008K, 0% used [0xb9000000,0xb9000000,0xb92f0000) >>> from space 84224K, 99% used [0xb92f0000,0xbe51a010,0xbe530000) >>> to space 128K, 0% used [0xbe530000,0xbe530000,0xbe550000) >>> PSOldGen total 174784K, used 6136K [0xc9000000, 0xd3ab0000, >>>0xe9000000) >>> object space 174784K, 3% used [0xc9000000,0xc95fe3a8,0xd3ab0000) >>> PSPermGen total 16640K, used 16465K [0xe9000000, 0xea040000, >>>0xf9000000) >>> object space 16640K, 98% used [0xe9000000,0xea014600,0xea040000) >>>64676.110: [Full GC 90272K->6157K(262016K), 0.6643557 secs] >>> Heap after GC invocations=2134: >>> >>>---------------------------------------------------------------- >>> PSYoungGen total 86976K, used 83817K [0xb9000000, 0xbe550000, >>>0xc9000000) >>> eden space 3008K, 0% used [0xb9000000,0xb9000000,0xb92f0000) >>> from space 83968K, 99% used [0xb92f0000,0xbe4ca6c8,0xbe4f0000) >>> to space 384K, 0% used [0xbe4f0000,0xbe4f0000,0xbe550000) >>> PSOldGen total 174784K, used 6955K [0xc9000000, 0xd3ab0000, >>>0xe9000000) >>> object space 174784K, 3% used [0xc9000000,0xc96caea8,0xd3ab0000) >>> PSPermGen total 17664K, used 17337K [0xe9000000, 0xea140000, >>>0xf9000000) >>> object space 17664K, 98% used [0xe9000000,0xea0ee670,0xea140000) >>>71170.151: [Full GC 90773K->7168K(261760K), 1.0508560 secs] >>> Heap after GC invocations=2348: >>> >>> >>> >>> >>> >>> >> >> >> >> > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Find out how CFTicket can increase your company's customer support efficiency by 100% http://www.houseoffusion.com/banners/view.cfm?bannerid=49 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:207246 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
