我们的zimbra服务器每隔几天都会遇到不明原因的延迟，只有在重新启动服务器后才能解决。 从最终用户的angular度来看，如果他们使用networking邮件，并发送消息，那么最终会超时。 从系统terminallogin，切换用户以及重新启动zimbra服务都会变慢。 使用'su – '需要2分钟的时间来更改用户
重新启动所有的zimbra服务，dns服务，不能解决问题。 问题只有在完全重新启动后才能解决。 重新启动后，login，切换用户和重新启动服务器很快就会发生。
我们正在使用dnsmasq进行拆分DNS，这是因为NAT导致我们的环境所需要的。 但是，查询DNS会立即返回结果。 我们正在使用外部ldap数据库进行身份validation，但没有其他服务器使用它显示任何问题，也没有负载问题。 其他一切都是默认的安装和configuration。
系统日志中没有明显的错误。 服务器负载（磁盘IO）在发生问题和没有问题时是相同的。
最初这一般是在星期一或星期二每星期发生一次。 本周发生在星期一和星期四。
我的版本是：
zimbra @ servername〜$ zmcontrol -v版本7.2.1_GA_2790.RHEL6_64_20120815212147 UNKNOWN_64 FOSS版本。
有没有人遇到或解决过这样的问题？
我发现rsyslog在通过TCP将日志转发到远程主机时，有时会在无法转发到远程主机时挂起。 即使远程主机恢复运行，rsyslog仍然是挂起的，因此减慢了系统中所有尝试login的内容。 重新启动rsyslog时会发生这种情况，但通过cron作业定期重新启动它似乎从来没有为我工作。 我发现的最好的解决办法是没有远程主机太多了。 🙂
但是，可以对rsyslog进行调整，使其排队而不是locking。 您可能仍会遇到此问题，在这种情况下，直到rsyslog重新启动才会转发日志，但不会影响整个系统。
注释掉你当前的转发规则，把它放在你的rsyslog.conf的末尾：
$WorkDirectory /var/spool/rsyslog # where to place spool files $MainMsgQueueFileName mainqueue # unique name prefix for spool files $MainMsgQueueMaxDiskSpace 2g # 1gb space limit (use as much as possible) $MainMsgQueueSaveOnShutdown on # save messages to disk on shutdown $MainMsgQueueType LinkedList # run asynchronously $MainMsgResumeRetryCount -1 # infinite retries if host is down *.* @@1.2.3.4:514 # replace this with your own forwarding rule 您将需要确保/ var / spool / rsyslog存在，因为否则将不会创build它。