Do any of these describe your Zimbra system?
- You have a large mail store (1TB or more)
- Your Zimbra system is busy with a lot of inbound and/or outbound emails every day
- You keep backups for a long time
- You believe you have plenty of RAM but you are finding that your Zimbra server is swapping more than you would expect
If so, then this tip is for you!
Keep updatedb Away From Zimbra
updatedb is the utility that manages the database used by the Linux utility mlocate (i.e. the “locate” command). It’s installed in Ubuntu by default, but is optionally installed in CentOS/RHEL Every day, the mlocate script that calls updatedb is executed as one of the scripts in /etc/cron.daily.
updatedb uses a lot of RAM and a lot of CPU to keep track of all of the file system changes each time it runs every 24 hours. This is so the mlocate utility can find files fast.
Zimbra however, does not rely on the mlocate utility at all. Zimbra’s crontab for example contains entries that use the “find” command, not the “locate” command. I am sure Zimbra does not use “locate” at all because I opened a Support case with Zimbra to ask them, and they told me nothing in Zimbra ever calls the “locate” command.
So why then are we wasting resources every 24 hours trying to keep a database of all of the files in the /opt/zimbra tree up to date? (That’s a rhetorical question Sparky…)
In other words, how do we keep the option to use mlocate to find operating system files, but keep updatedb away from our Zimbra installation?
Easy! In Ubuntu, just add “/opt” to the PRUNEPATHS directive in /etc/updatedb.conf, so that it looks something like this:
root@mb18:~# cat /etc/updatedb.conf
PRUNE_BIND_MOUNTS="yes"
# PRUNENAMES=".git .bzr .hg .svn"
PRUNEPATHS="/opt /tmp /var/spool /media /home/.ecryptfs /var/lib/schroot"
PRUNEFS="NFS nfs nfs4 rpc_pipefs afs binfmt_misc proc smbfs autofs iso9660 ncpfs coda devpts ftpfs devfs mfs shfs sysfs cifs lustre tmpfs usbfs udf fuse.glusterfs fuse.sshfs curlftpfs ecryptfs fusesmb devtmpfs"
root@mb18:~#
The location varies on CentOS/RHEL systems BTW… I’ve done this now on several Ubuntu Zimbra mailbox servers that had been swapping as much as 9GB, and subsequently watched swap file growth revert to no more than a few hundred MBs.
Need help with improving the performance of your Zimbra environment? Fill out the form to start the conversation!
Hope that helps,
L. Mark Stone
Mission Critical Email
16 January 2020
The information provided in this blog is intended for informational and educational purposes only. The views expressed herein are those of Mr. Stone personally. The contents of this site are not intended as advice for any purpose and are subject to change without notice. Mission Critical Email makes no warranties of any kind regarding the accuracy or completeness of any information on this site, and we make no representations regarding whether such information is up-to-date or applicable to any particular situation. All copyrights are reserved by Mr. Stone. Any portion of the material on this site may be used for personal or educational purposes provided appropriate attribution is given to Mr. Stone and this blog.