I traced the problem to the infrastructure I was using to talk to the
database--JDO (0.9) !!
It seems the leak was there all along, but in the heavy duty use in the
64 bit environment, it became more "visible."
Have moved the database connectivity to OJB and the problem seems to
have gone away.
Thank you all for the help/info.
Paul
On 10/21/2011 9:31 AM, Nathaniel, Alfred wrote:
Java GC tuning is something of a black art.
The default settings are not suitable for a large servlet container, and they
also depend on the Java version.
I don't have experience with Java7 but with jdk1.6.0_24 (SPARC Solaris) we are
using:
-server -d64 -XX:CodeCacheMinimumFreeSpace=10M -XX:ReservedCodeCacheSize=100M
-Xms6000m -Xmx6000m -XX:PermSize=300m -XX:MaxPermSize=300m
-Xloggc:/home/online/tomcat_cocoon0a_1/logs/gc.log -XX:+PrintGCTimeStamps
-XX:+PrintGCDetails -XX:+PrintTenuringDistribution -XX:+UseConcMarkSweepGC
-XX:+UseParNewGC -XX:NewRatio=4 -XX:SurvivorRatio=6 -XX:TargetSurvivorRatio=90
-XX:MaxTenuringThreshold=5 -XX:MaxGCPauseMillis=5000
Look at the gc.log output and GC generation sizes to find out whether you have
a memory leak, too little memory, or are wasting memory.
Remember that with a 64bit JVM all your pointers are twice as big.
At 3500M your are just at the limit what can be reached with 32bit.
You can also try -XX:+UseCompressedOops to reduce memory in the 64bit JVM.
HTH, Alfred.
-----Original Message-----
From: Robby Pelssers [mailto:[email protected]]
Sent: Freitag, 21. Oktober 2011 15:05
To: [email protected]
Subject: RE: scaling problem
Ow.. not sure about that.. I'd almost think not but you better check to be sure.
-----Original Message-----
From: Paul Joseph [mailto:[email protected]]
Sent: Friday, October 21, 2011 3:04 PM
To: [email protected]
Subject: Re: scaling problem
Ah interesting...does it apply to Cocoon 2.1.11 (should have mentioned
earlier, that's what I am using.)
On 10/21/2011 8:44 AM, Robby Pelssers wrote:
For what it's worth... check this thread and see if this applies:
http://www.mail-archive.com/[email protected]/msg45665.html
Robby
-----Original Message-----
From: Paul Joseph [mailto:[email protected]]
Sent: Friday, October 21, 2011 2:42 PM
To: [email protected]
Subject: scaling problem
Hi there,
I have been supporting a cocoon app for several years and it has been
quite successful when about 10 users are accessing it at the same time,
in the 32 bit Windows/Tomcat envrionment.
Now, the app is being used by larger groups and in higher numbers. So I
put it on in Windows 64 bit, using the new JDK 7 64 bit release and
Tomcat 64, all on a server class machine.
I specified max memory to be 3500 MB.
A recent load test showed that searches are a problem. When a user runs
a search and retrieves 1000 records, after several users doing this
several times, the JVM runs out of memory.
I estimate it takes a retrieval of a total of 500,000 records (adding up
each user's queries) before the server runs out of memory...
I tried the new garbage collector by specifying in Tomcat's Java options
-XX:+UseG1GC but this seems to have little effect.
Any suggestions would be appreciated.
thx.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
The content of this e-mail is intended only for the confidential use of the
person addressed.
If you are not the intended recipient, please notify the sender and delete this
e-mail immediately.
Thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
