performance on test box

[wokka]

Hello everyone, I set this up with FC3 with no issues, the install was painless. I've setup a couple of users just to demonstrate this to my clients who want an Exchange alternative. I'm running my demo box on an old Intel p2-400 with 256 megs of ram. With no clients connected, its running about 1.7 to 1.8 load average and I see two java processes that go from 25 to 75% on cpu all the time.

I know this is a weak box, but with it sitting there idle, how come java is eating up so much cpu? I know this is beta, but thought I would ask to see if I had something borked up. I did a minimal install of FC3 and then added the 3 packages that are required, libidn, curl and fetchmail, then did an install.

I'm attaching a file called temp.txt, its a complete list of all processes running, using ps auxw

Thanks!

[KevinH]

The big problem is RAM. With 256 your way below our recommended and 256 below our minimum of 512Meg. This will cause lots of swapping. The CPU issue you see is from our process mon. Can you run top and vmstat 5 and report the output?

Can you tell which of the three Java processes seem to be eating CPU? I did a ps -ef on my test box and got back these two, but this is a slightly older version.

zimbra 2236 1 0 Sep16 ? 00:00:03 /opt/zimbra/java/bin/java -client -XX:NewRatio=2 -Xms1188m -Xmx1188m -Djava.library.path=/opt/zimbra/lib -Djava.endorsed.dirs=/opt/zimbra/tomcat/common/endorsed -classpath :/opt/zimbra/tomcat/bin/bootstrap.jar:/opt/zimbra/tomcat/bin/commons-logging-api.jar -Dcatalina.base=/opt/zimbra/tomcat -Dcatalina.home=/opt/zimbra/tomcat -Djava.io.tmpdir=/opt/zimbra/tomcat/temp org.apache.catalina.startup.Bootstrap start
zimbra 31102 31083 13 09:52 ? 00:00:00 /opt/zimbra/java/bin/java -client -Dzimbra.home=/opt/zimbra -cp /opt/zimbra/lib/zimbrastore.jar:/opt/zimbra/lib/commons-logging.jar:/opt/zimbra/lib/commons-cli-2.0.jar:/opt/zimbra/lib/dom4j-1.5.jar:/opt/zimbra/lib/log4j-1.2.8.jar:/opt/zimbra/lib/commons-httpclient-2.0.1.jar com.zimbra.cs.localconfig.Main -q -m shell mysql_directory mysql_socket zimbra_mysql_user zimbra_mysql_password

[wokka]

ram makes sense... I'll get this installed onto a production box with more ram and scsi drives soon and give it a whirl.

I'm attaching a top, ps -ef | grep java and the vmstat for you to see...

Thanks!

[anand]

there are two problems - we have a watchdog script tied into zmcontrol which is something we have rethought - that fix should take care of the periodic spikes. Secondly, all the start/stop/status scripts could/will/need to also be much faster.

Don't know what to tell you except to wait for the next build where this will be fixed.

JVM + swap is not a good situation at all. JVMs deteriorate pretty bad if they are not resident - one of the downsides of GC. In your case though, vmstat shows no swapping (atleast when you ran the vmstat). But in general, this is something to eliminate. While trying to eliminate swap one of the things you can try is to edit the zmjava and zmlocalconfig scripts to make sure -Xmx is set really low, but not too low.

You could probably get it to work, but we do recommend more RAM.

[wokka]

ok, so my install is ok, and nothing is out of the ordinary per how this version of the beta was designed... that is what I was after.

This box was just used for a technology test/demo of the software and to show some potential clients.

I'm eagerly waiting the next version and the release of the network version.