Java eating CPU

[NoDoze]

To share my experience...

I just completed a migration from our production server, to a backup server, then back to the production server all due to a dead hard drive.

On the original server, a dual quad core xeon with 4GB mem, I had the /opt/ directory on the same partition as the CentOS 5.3, on a RAID1. CPU usage was constantly at 30-80% due to the java process.

On the backup server, a pentium D 3.4 with 2GB mem, centos 5.3, when I mirrored everything to the backup server, I set the /opt/ directory on a separate RAID1 from the OS RAID1. Immediately I saw the cpu usage drop to 10-25% due to the java process.

Then when I mirrored everything back to the original production server, this time with the /opt/ on a separate RAID1 from the OS RAID1, again the cpu usage dropped to now 0-3% due only to the java process.

I dunno what the java process is doing, and why the separation of the /opt/ directory made such a huge difference, but why did hardware play into the java/cpu usage...?

[LMStone]

Originally Posted by NoDoze

To share my experience...

I just completed a migration from our production server, to a backup server, then back to the production server all due to a dead hard drive.

On the original server, a dual quad core xeon with 4GB mem, I had the /opt/ directory on the same partition as the CentOS 5.3, on a RAID1. CPU usage was constantly at 30-80% due to the java process.

On the backup server, a pentium D 3.4 with 2GB mem, centos 5.3, when I mirrored everything to the backup server, I set the /opt/ directory on a separate RAID1 from the OS RAID1. Immediately I saw the cpu usage drop to 10-25% due to the java process.

Then when I mirrored everything back to the original production server, this time with the /opt/ on a separate RAID1 from the OS RAID1, again the cpu usage dropped to now 0-3% due only to the java process.

I dunno what the java process is doing, and why the separation of the /opt/ directory made such a huge difference, but why did hardware play into the java/cpu usage...?

If the CPU is waiting around for things to happen, you'll see higher CPU usage and higher loads in top.

Disk bottlenecks can often be represented in top via the %wa metric (percentage wait); most %wa is I/O, and the slowest I/O is generally disk. So unless you have memory thrashing or other non-disk I/O waits, %wa is generally a good proxy for disk bottlenecks.

Zimbra is very disk intensive, and not all of the disk activity takes place in the /opt/zimbra tree, so any improvement to the disk subsystem can have big benefits.

Hope that helps,
Mark

[Fox_sibirsky]

I use zimbra 6.01 ubuntu hardy x64. On my store&logger server in multiserver installation java periodically eat all 3vcpu, otherwise on store server without logger java work correctly.
I solved this use autorestart zmloggerctl every 4 hours