[Contrib: Evaluation System] sakai 2.5.3 performance

[Hedrick Charles]

Unfortunately top output wont' help, because it doesn't show how close you were to running out of space inside the jvm. The way we watch jvm performance is with

  jstat -gc 5000

to a file. Do it long enough for several GC cycles to happen. Since memory grows over time, you actually have to do the test as long as you expect to go between restarts of the JVM. Even the output from my JSP at the end of the time would be useful.


On Apr 2, 2011, at 5:05:51 PM, Eduardo Zavala wrote:

> Hy, thanks a lot for tell me your experience!!, my function is evaluate if the application will performance good with a big number of sessions, the idea is that will access nearly5000 cuncurrent connections.
> System area give me the binaries of the application and I must do the testings without install or set nothing on the application, I must use linux admin tools to monitor process, memory, disk and network like sar, top, netstat....
> May be the unique settings that I can do is adding more physical memory to linux or tune the java parameters
> 
> Example of real cofiguration with 100 concurrent users
> 
> ps -fe | grep sakai
> 
> sakai 19416 1 0 Apr01 ? 00:17:31 /usr/java/jdk1.5.0_17/bin/java -server -XX:+CMSPermGenSweepingEnabled -Xms768m -Xmx2048m -XX:MaxPermSize=512m -Djava.awt.headless=true -Duser.language=es -Duser.region=ES -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.util.logging.config.file=/u01/sakai/conf/logging.properties -Djava.endorsed.dirs=/u01/sakai/common/endorsed -classpath :/u01/sakai/bin/bootstrap.jar:/u01/sakai/bin/commons-logging-api.jar -Dcatalina.base=/u01/sakai -Dcatalina.home=/u01/sakai -Djava.io.tmpdir=/u01/sakai/temp org.apache.catalina.startup.Bootstrap start
> 
> top - 18:01:43 up 124 days, 6:22, 1 user, load average: 0.27, 0.10, 0.02
> Tasks: 114 total, 1 running, 113 sleeping, 0 stopped, 0 zombie
> Cpu(s): 0.3%us, 0.2%sy, 0.0%ni, 99.3%id, 0.0%wa, 0.1%hi, 0.2%si, 0.0%st
> Mem: 3896216k total, 3761404k used, 134812k free, 222120k buffers
> Swap: 4194296k total, 993848k used, 3200448k free, 659352k cached
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 19416 sakai 21 0 2929m 1.0g 52m S 2 28.1 17:35.45 java
> 
> 
> 
> 
>   
> Subject: Re: [Contrib: Evaluation System] sakai 2.5.3 performance
> From: hedrick at rutgers.edu
> Date: Sat, 2 Apr 2011 12:02:31 -0400
> CC: evaluation at collab.sakaiproject.org
> To: eduzav at hotmail.com
> 
> I can't answer your question because I've never used a JVM that small in production. We have a 1 GB JVM on our primary test system, but we've never put more than a few users on it.
> 
> I'd like to point out that it's not just the number of concurrent connections. Data about users and sites is cached. Larger institutions will tend to have more connections, more users and more sites, so it may all go together, but there's a basic overhead that isn't dependent upon number of current connections.
> 
> Also, watch your memory usage. It will tend to grow over time. I've never been clear whether this is caches growing or a memory leak. I suspect a memory leak. We have to restart every few weeks, or the system will go into continuous garbage collection. I'm attaching something you can put in tomcat/webapps/ROOT to print out memory usage. It shows current usage, usage as of the last GC, and the maximum usage after a GC. That will let you judge whether memory use is getting dangerously large. (For anything other than current usage to work, it has to be called soon after the JVM is started. We call it from a cron job, and put the output in a file. That lets us watch memory usage over time.) You call it as SITENAME/memstats.jsp.
> 
> Also, I would strongly recommend against doing a new installation of a version that old.  Newer versions perform better and have bug fixes, including a few security-related. I don't believe 2.5 is still supported.
> 
> At this point I'd use 2.7.1.
> 
> With a 10.5 GB JVM (using the size of -mx – in fact the image is larger, because there are things not counted in -mx), we routinely get around 2500 sessions on one system. This is the count shown in Sakai. Not all of those are actually doing anything, since Sakai will keep sessions around for a couple of hours before timing them out. 
> 
> We see up to 500 threads in the JVM. Tomcat tries to control the number of threads at a time. It will hold incoming connections until there's a free thread. This made sense 10 years ago with limited memory. Today I don't think it makes sense any more. In the <Connector configuration statements we set maxThreads="2000", which is intended to be large enough not to be a limit.
> 
> 
> 
> On Mar 31, 2011, at 11:34:28 PM, Edu Hotmail wrote:
> 
> I'm newby configuring tomcat and java, I'm going to install sakai 2.5.3 on linux centos 5.5 with 3gb ram . The database is on other linux with 4gb ram using oracle database 10g.
> I need to estimate how many concurrent network connections can support the tomcat sakai for working with an optimal performance using the previous configuration...
> How is the relationship between tomcat java memory used and concurrent network connection permitted?
> Thanks a lot,
> Edu
> _______________________________________________
> evaluation mailing list
> evaluation at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/evaluation
> 
> TO UNSUBSCRIBE: send email to evaluation-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/evaluation/attachments/20110402/ea38230b/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3817 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/evaluation/attachments/20110402/ea38230b/attachment-0001.bin