Zimbra 开源软件出现无法解释的减速现象，只有通过重启才能解决

Question

我们的 zimbra 服务器每隔几天就会出现无法解释的减速，只有重新启动服务器后才能解决。从最终用户的角度来看，如果他们使用 Webmail 并发送消息，那么它最终会超时。从系统终端来看，登录、切换用户和重新启动 zimbra 服务时速度会变慢。使用“su -”更改用户最多需要 2 分钟

重新启动所有 zimbra 服务、dns 服务无法解决问题。只有完全重新启动后问题才会解决。重新启动后，登录、切换用户和重新启动服务器都会很快完成。

由于 NAT，我们使用 dnsmasq 进行拆分 DNS，这是我们环境所需要的。但查询 DNS 会立即返回结果。我们使用外部 ldap 数据库进行身份验证，但使用它的其他服务器均未出现任何问题，并且也没有负载问题。其他一切都是默认安装和配置。

系统日志里没有明显错误，出现问题和没出现问题时服务器负载、磁盘IO都是一样的。

最初这种情况每周发生一次，通常是在周一或周二。本周，它发生在周一和周四。

我的版本是：

zimbra@servername ~ $ zmcontrol -v Release 7.2.1_GA_2790.RHEL6_64_20120815212147 UNKNOWN_64 FOSS 版本。

有没有人遇到或解决过这样的问题？

Answer 1

我发现，当 rsyslog 通过 TCP 将日志转发到远程主机时，如果无法转发到远程主机，它有时会挂起。即使远程主机恢复，rsyslog 仍会挂起，从而减慢系统上尝试记录的所有其他内容的速度。发生这种情况时，重新启动 rsyslog 可以解决问题，但通过 cron 作业定期重新启动它似乎对我来说不起作用。我发现的最佳解决方案是不要让远程主机停机太多。:)

但是，可以对 rsyslog 进行一些调整，使其排队而不是锁定。您可能仍会遇到此问题，在这种情况下，除非重新启动 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 存在，否则它将不会创建它。