This article describes the actions I took over the years to improve the CPU usage of Zimbra in my Virtual Machine running on VMware ESX. I’m using Zimbra since 2007.
Zimbra Version 5.0.14 (2008)
I encountered a problem on my VM which is running Zimbra .
Every 1 minute I got a cpu spike of around 70% to 80% 24hrs a day and I don’t know why. Looks lika a JAVA process is responsible for this when I watch TOP output. I would like to get rid of this!
changes that did not help:
– ‘Sleep time between subsequent mailbox purges’ from 1 minute to 1 hour
– fetchmail from 1 minute to 5 minutes
– disabling or editing cronjobs:
#*/2 * * * * /opt/zimbra/libexec/zmstatuslog #*/10 * * * * /opt/zimbra/libexec/zmdisklog #00,10,20,30,40,50 * * * * /opt/zimbra/libexec/zmlogprocess > /tmp/logprocess.out 2>&1 00,20,40 * * * * /opt/zimbra/libexec/zmlogprocess > /tmp/logprocess.out 2>&1 #0,10,20,30,40,50 * * * * /opt/zimbra/libexec/zmqueuelog 10,30,50 * * * * /opt/zimbra/libexec/zmqueuelog
– “$ zmloggerctl stop” did not help
– vi /opt/zimbra/libexec/zmlogprocess
#my $rawRetention = `${zimbra_home}/bin/zmprov -l gacf | egrep '^zimbraLogRawLifetime' | sed -e 's/zimbraLogRawLifetime: //'`; my $rawRetention = "31d"; #my $summaryRetention = `${zimbra_home}/bin/zmprov -l gacf | egrep '^zimbraLogSummaryLifetime' | sed -e 's/zimbraLogSummaryLifetime: //'`; my $summaryRetention = "730d";
But then I found it. The zmmtaconfig has a watchdog process that will run every sixty seconds and restart services if they have crashed. I haven’t had the services crash so I changed the value to five minutes. If you care about uptime should a service crash you shouldn’t change this. However depending on when the service crashed it could be restarted sooner than five minutes.
# su - zimbra # zmlocalconfig -e zmmtaconfig_interval=300
..
This is what someone else configured to overcome these problems and boost performance:
su – zimbra
zmlocalconfig -e zmmtaconfig_interval=6000
zmprov mcf zimbraLogRawLifetime 7d
zmprov mcf zimbraLogSummaryLifetime 30d
/opt/zimbra/libexec/zmlogprocess
su – zimbra
crontab -e
*/60 * * * * /opt/zimbra/libexec/zmstatuslog
Zimbra Version 6.0.1 (2009)
After updating Zimbra 5.0.14 to 6.0.1 I ran into a same sort of problem again. The zimbralogger was using the CPU like crazy.
I executed the folowing command to stop te logging process and CPU went down from 50% with to 5% flat(!):
$ su - zimbra $ zmprov ms fill_in_your_hostname -zimbraServiceEnabled logger
Then as the root user edit /etc/logrotate.d/zimbra and comment out all logger related start / reload commands e.g.
# su - zimbra -c "/opt/zimbra/bin/zmswatchctl restart" > /dev/null 2>&1 || true # su - zimbra -c "/opt/zimbra/bin/zmlogswatchctl start"
Now I got a great load average once again: 0.03, 0.10, 0.21
Zimbra Version 6.0.7 (20 aug 2010)
Still the same issues after installing v 6.0.7 on a Fedora Core 11 x64 virtual machine on ESX4.1. Applied the same tricks to bring down CPU usage.
Zimbra Version 7.0.0 (07 febr 2011)
Looks like the problem is solved in version 7.0.0, read more here. I upgraded from version 6.0.10 and the cpu spikes are not there anymore.. And finally an upgrade introduced some new interesting features.
Zimbra Version 7.1.4 (febr 2012) and 7.2.0 (june 2012)
Got the problem again in 7.1.4. Really annoying. An upgrade to 7.2.0 also did not solve this. Only things that helped:
- # su – zimbra
# zmconfigdctl stop
# zmlocalconfig -x | grep zmmtaconfig
zmmtaconfig_enable_config_restarts = true
zmmtaconfig_interval = 6000
zmmtaconfig_listen_port = 7171
zmmtaconfig_log_level = 3
zmmtaconfig_watchdog = FALSE
Problem not solved, just a small improvement. - Installed a new version of Zimbra 7.2 on Centos 6.2 (instead of Fedora 11) and migrated the mailboxes. This was the only thing I could do that finally solved the very annoying problem. Not good.
Zimbra Version 8.0.2 (febr 2013)
After upgrading from 7.2.0 to 8.0.2 I just had to adjust the crontab file as user zimbra to reduce the repetitive tasks that are planned every 5 and 10 minutes. The CPU is very low.
Zimbra is curently running on Centos 6.2 (minimal install) on VMware 5.1 on a SSD disk.
Leave a Reply