Назад | Перейти на главную страницу

Zimbra с открытым исходным кодом испытывает необъяснимые замедления, которые решаются только после перезагрузки

Наш сервер zimbra каждые пару дней испытывает необъяснимые замедления, которые разрешаются только после перезагрузки сервера. С точки зрения конечного пользователя, если они используют веб-почту и отправляют сообщение, то в конечном итоге оно истечет. С системного терминала происходит замедление входа в систему, переключение пользователей и перезапуск служб zimbra. Смена пользователя с помощью su - занимает до 2 минут.

Перезапуск всех служб zimbra, служб DNS, проблему не решает. Проблема решается только после полной перезагрузки. После перезагрузки вход в систему, переключение пользователей и перезапуск серверов происходят быстро.

Мы используем dnsmasq для разделения DNS, который необходим нашей среде из-за NAT. Но запрос DNS немедленно возвращает результаты. Мы используем внешнюю базу данных ldap для аутентификации, но никакие другие серверы, использующие ее, не показывают каких-либо проблем, и на ней также нет проблем с загрузкой. Все остальное - установка и настройка по умолчанию.

В системных журналах явных ошибок нет. Нагрузка на сервер, дисковый ввод-вывод, одинакова, когда есть проблема и когда нет проблем.

Первоначально это происходило один раз в неделю, обычно в понедельник или вторник. На этой неделе это произошло в понедельник и четверг.

Моя версия:

zimbra @ servername ~ $ zmcontrol -v Выпуск 7.2.1_GA_2790.RHEL6_64_20120815212147 UNKNOWN_64 FOSS edition.

Кто-нибудь сталкивался или решал такую ​​проблему?

Я обнаружил, что 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 существует, потому что иначе он не создаст его.