Actually, now I am wondering if there is a leak in Cocoon 2.1.11...
After the memory used by the JVM reached its max and brought the Tomcat
application to a halt, I I logged out all users and confirmed that the
memory was fully used both using Tomcat's Manager and with the
performance monitoring tool on Windows 2008 R3 (running as a VM on a two
CPU AMD machine).
I noted the time.
One hour later, both the Tomcat manager and the montioring tool, report
no change in memory status--nothing got freed up.
But when I stop the Tomcat service, all the memory is reclaimed...
I paste the details from Tomcat Manager below (FYI)
thx.
Paul
===================
From Tomcat Manager.
Physical memory: 4095.55 MB Available memory: 245.19 MB Total page file:
9361.70 MB Free page file: 4587.53 MB Memory load: 94
Process kernel time: 17.75 s Process user time: 194.796 s
JVM
Free memory: 83.42 MB Total memory: 3584.00 MB Max memory: 3584.00 MB
"ajp-apr-8009"
Max threads: 200 Current thread count: 0 Current thread busy: 0 Keeped
alive sockets count: 0
Max processing time: 0 ms Processing time: 0.0 s Request count: 0 Error
count: 0 Bytes received: 0.00 MB Bytes sent: 0.00 MB
"http-apr-8080"
Max threads: 200 Current thread count: 10 Current thread busy: 1 Keeped
alive sockets count: 0
Max processing time: 82736 ms Processing time: 226.617 s Request count:
383 Error count: 3 Bytes received: 0.02 MB Bytes sent: 5.02 MB
Start time: Fri Oct 21 09:25:26 EDT 2011 Startup time: 0 ms TLD scan
time: 15 ms
Active sessions: 0 Session count: 0 Max active sessions: 0 Rejected
session creations: 0 Expired sessions: 0 Longest session alive time: 0 s
Average session alive time: 0 s Processing time: 0 ms
JSPs loaded: 1 JSPs reloaded: 1
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:robby.pelss...@nxp.com]
Sent: Freitag, 21. Oktober 2011 15:05
To: users@cocoon.apache.org
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:pjos...@gmail.com]
Sent: Friday, October 21, 2011 3:04 PM
To: users@cocoon.apache.org
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/users@cocoon.apache.org/msg45665.html
Robby
-----Original Message-----
From: Paul Joseph [mailto:pjos...@gmail.com]
Sent: Friday, October 21, 2011 2:42 PM
To: users@cocoon.apache.org
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: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
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: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
