As specified in
Performance Tuning Guidelines for Large Deployments - Zimbra :: Wiki
...I modified the following settings in an attempt to improve IO performance. What I didn't realize is that these changes are for 5.x only. Thanks to Mike from Zimbra for pointing that one out.
OLD < table_cache = 500
---
NEW > table_cache = 2600
OLD < innodb_open_files = 500
---
NEW > innodb_open_files = 2600
NEW > innodb_max_dirty_pages_pct = 10
NEW > innodb_flush_method = 0_DIRECT
Upon initial restart, zimbra behaved normally. MySQL was behaving as expected, and mail was flowing in and out. However, I found that tomcat was failing to start correctly I did not connect the tomcat problems to the change in MySQL's caching behaviour, as MySQL was running normally.
I found the following errors in catalina.out, which is tomcat's startup log file:
Interesting errors in catalina.out:
Code:
SEVERE: Error starting static Resources
java.lang.IllegalArgumentException: Document base /opt/zimbra/apache-tomcat-5.5.15/server/webapps/host-manager does not exist or is not a readable directory
Code:
SEVERE: Error starting static Resources
java.lang.IllegalArgumentException: Document base /opt/zimbra/apache-tomcat-5.5.15/server/webapps/manager does not exist or is not a readable directory
Code:
WARNING: A docBase /opt/zimbra/apache-tomcat-5.5.15/webapps/zimbra inside the host appBase has been specified, and will be ignored
Extensive investigation of these issues turned up many false leads. I spent a good deal of time investigating permissions issues, potential imapproxy problems, and issues with zimbra's logger.
After more investigation, I found the following in zimbra's mailbox log:
2009-04-09 02:27:06,620 FATAL [main] [] system - Config initialization failed
com.zimbra.common.service.ServiceException: system failure: getting all config entries
Caused by: java.sql.SQLException: Incorrect information in file: './zimbra/config.frm'
Query being executed when exception was thrown:
SELECT * FROM config
at com.mysql.jdbc.SQLError.createSQLException(SQLErro r.java:946)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.ja va:2870)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:15 73)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java :1665)
at com.mysql.jdbc.Connection.execSQL(Connection.java: 3124)
at com.mysql.jdbc.PreparedStatement.executeInternal(P reparedStatement.java:1149)
at com.mysql.jdbc.PreparedStatement.executeQuery(Prep aredStatement.java:1262)
at org.apache.commons.dbcp.DelegatingPreparedStatemen t.executeQuery(DelegatingPreparedStatement.java:20 5)
at com.zimbra.cs.db.DbConfig.getAll(DbConfig.java:155 )
... 40 more
This pointed directly at a problem when querying MySQL. It was only at that point that I connected the innodb table cache handling change with tomcat's problems. I re-enabled the old my.cnf config, restarted all services, and tomcat fired back up.
Cheers,
JHM