Как найти причину медленного входа через Dovecot

Если почтовый клиент долго подключается, не начинайте с увеличения process_limit и покупки дисков. Сначала разделите этапы: TCP/TLS, входной процесс Dovecot, проверка пароля через passdb, поиск параметров пользователя и открытие почтового ящика. По логам и замерам станет видно, где появляется задержка и что именно проверять дальше.

Сначала определите, на каком этапе возникает задержка

В моей практике фраза «почта тормозит» обычно смешивает несколько разных событий. Клиент может долго устанавливать TCP-соединение, ждать TLS, проходить аутентификацию, получать список папок или синхронизировать заголовки. Это разные операции и разные места поиска. Если пользователь уже видит письма, но клиент еще долго крутит индикатор, причина может быть в синхронизации папок, а не во входе. Если не появляется даже запрос пароля, смотреть надо еще раньше — в доступность сервиса и сетевой путь. Один общий секундомер на весь процесс здесь мало что объясняет.

Я прошу записать точное время попытки и сравнить его с журналом Dovecot и журналами клиента или прокси, если он есть. В разных установках Dovecot пишет в journald, syslog или заданные файлы, поэтому путь /var/log/mail.log нельзя объявлять универсальным. Команда doveadm log find помогает определить доступные журналы в поддерживаемой конфигурации; если команда не подходит конкретной версии или сборке, смотрю log_path, info_log_path и настройки системного журналирования. Для проверки эффективной конфигурации использую doveconf -n. В настройке корпоративной почты такие мелочи важнее эффектной правки лимита: сначала надо понять, какой именно процесс молчит.

Для условной компании «Вереск-Сервис» я бы начал с короткого сценария: один тестовый пользователь, одно и то же рабочее место, фиксированное время проверки, затем повтор с другого устройства. Записываем отдельно время установки соединения, ответ на аутентификацию и момент появления папок. Так можно сравнить одиночный вход с утренним всплеском и не спутать задержку конкретной учетной записи с общей проблемой сервера. Это не отчет о проведенных работах и не обещание результата: без журналов и замеров точную причину назвать нельзя. Зато такой сбор фактов занимает меньше времени, чем несколько случайных перезапусков.

• Зафиксируйте время и учетную запись теста.
• Разделите подключение, аутентификацию и синхронизацию папок.
• Определите журналы через настройки вашей сборки.

Что означает предупреждение о process_limit

В Dovecot process_limit — верхняя граница числа процессов конкретной службы. У IMAP-входа есть, например, отдельная служба imap-login, а у обработки IMAP-сессий — imap; значения и роль лимита зависят от блока службы. Это не универсальная настройка «сколько пользователей может войти». На общую емкость влияют также client_limit, service_count, число соединений на пользователя, ресурсы машины и версия Dovecot. В официальной документации Dovecot отдельно описаны классы служб: imap выполняет блокирующие операции ввода-вывода, а imap-login обслуживает входные соединения. Переносить настройку одной службы на другую — способ получить новый симптом вместо старого.

Предупреждение service(imap-login): process_limit reached полезно как улика: лимит соответствующей службы достигнут. Но оно само по себе не доказывает, что пользователям не хватает именно процессов imap-login, и не диктует, насколько поднимать ограничение. В официальной инструкции Dovecot для ряда вариантов настройки imap-login описан ориентир, связанный с числом ядер CPU, а размер допустимого числа соединений зависит от пары process_limit × client_limit. Это не рецепт для каждой установки и не обещание емкости для любого офиса. Проверяю также очередь соединений, файловые дескрипторы, загрузку CPU, доступность auth и задержки passdb/userdb. Журнал — показание прибора, а не диагноз врача.

Прежде чем менять лимит, я сверяю фактические блоки service в выводе doveconf -n с документацией именно той версии, которая установлена. Затем выясняю, какую службу называет сообщение, какой лимит исчерпан и есть ли одновременно признаки нехватки файловых дескрипторов или занятых процессов. На тестовом окне правку проверяют с учетом доступной памяти и ожидаемого числа соединений; после изменения проверяют запуск, журналы и несколько клиентских подключений. Просто увеличить число «на всякий случай» — плохая практика: лимиты в том числе ограничивают расход ресурсов и помогают не дать всплеску соединений съесть сервер целиком. Подробный разбор того, как Dovecot меняет структуру конфигурации, есть в статье о переходе конфигурации Dovecot 2.4.

• Проверьте точный блок службы и достигнутый лимит.
• Сопоставьте `process_limit` с `client_limit` и ресурсами.
• Не переносите значения из чужой версии без проверки.

Не путайте кэш писем с кэшем аутентификации

В исходной конфигурации статьи mail_cache был представлен как параметр, который запоминает пользователя и избавляет от запросов к SQL. Это неверное смешение двух механизмов. Кэш Dovecot для почтовых данных и индексов относится к метаданным писем; он не является общим переключателем кэширования паролей и записей учетных записей. Для результатов запросов passdb и userdb в документации Dovecot описаны отдельные настройки аутентификационного кэша, включая auth_cache_size и auth_cache_ttl. По умолчанию auth_cache_size = 0 отключает этот кэш в документации ветки 2.3. Установленные значения нужно читать в своей конфигурации, а не угадывать по названию похожего параметра.

Аутентификационный кэш может сократить повторные обращения к базе, но он меняет поведение проверки учетных данных. Dovecot описывает случаи, когда старая запись используется до истечения TTL, а также особую обработку ошибок базы и отрицательных результатов. Значит, включать кэш «на несколько минут для всех» без проверки последствий — не безобидная оптимизация. Перед изменением оцениваю частоту смены паролей и блокировок, требования к немедленному отзыву доступа, содержимое passdb/userdb, ключи кэша и поведение при недоступности базы. Если параметр включен, сверяю hit/miss и TTL штатными средствами, а не заключаю по одному удачному подключению.

Если SQL отвечает медленно, сначала измеряю сами запросы и соединение до СУБД, затем смотрю запросы passdb и userdb, планы запросов, блокировки и загрузку базы. В Dovecot эти базы решают разные задачи: passdb проверяет учетные данные, userdb возвращает сведения, нужные для сеанса пользователя. Не каждый вход обязательно означает одинаковое число одинаковых запросов: это зависит от конфигурации, схемы аутентификации и того, какие данные уже получены на предыдущем этапе. Поэтому утверждение «каждый вход создает тяжелую нагрузку на диск» ничем не помогает, пока нет измерений. Для проверки удельного поведения полезно выполнить тестовый lookup учетной записи и сопоставить его с журналом СУБД.

Почтовый mail_cache тоже может влиять на работу с письмами, особенно на получение метаданных и поиск, но эффект зависит от типа клиента и его привычек синхронизации. Например, клиенты, которые заранее забирают заголовки и хранят локальную копию, могут меньше выигрывать от серверного кэша метаданных, чем веб-почта, выполняющая поиск на сервере. Это совсем не обещает ускорить аутентификацию. Я разделяю проверку логина и проверку загрузки списка папок: кэшировать надо то узкое место, которое подтвердили замеры. Если пользователь входит быстро, но медленно видит старые письма, менять auth_cache_ttl — выстрел в соседнюю проблему. Смежный случай ограничений IMAP-соединений разобран в статье о лимите подключений пользователя.

• Для passdb/userdb проверяйте `auth_cache_*`.
• Для метаданных писем изучайте `mail_cache_*`.
• Перед включением кэша оцените срок актуальности учетных данных.

Механизмы входа не лечат медленную базу

Dovecot поддерживает механизмы SASL-аутентификации, которые задаются параметром auth_mechanisms. В конфигурациях часто встречаются plain и login, но сам факт их наличия не объясняет задержку в десятки секунд. Это названия способов передачи учетных данных на этапе протокольной аутентификации, а не переключатели скорости SQL. Если механизм лишний, он не обязательно заметно увеличивает время подключения; если база отвечает медленно, удаление механизма ее не ускорит. Я оставляю только то, что требуется реальным клиентам и соседним сервисам, но сначала проверяю совместимость и условия защищенного соединения.

Имена PLAIN и LOGIN не означают, что пароль следует отправлять по незащищенному каналу. В Dovecot отдельно настраиваются доступность механизмов и требования к TLS; важны ssl и disable_plaintext_auth, а также фактическое шифрование соединения. Нельзя повторять совет «включить plain и login», вырвав его из безопасной конфигурации. Проверяю согласованную политику на сервере и клиентах, актуальность сертификата, результат TLS-переговоров и конфигурацию конкретной версии. Отключать все незнакомые методы на бою на глаз — тот самый короткий путь, после которого утром звонят уже не про скорость, а про невозможность войти.

Если в журнале нет явной ошибки механизма, а задержка появляется между запросом пароля и ответом сервера, я смотрю на обработку запроса: auth-процессы, passdb, userdb и внешние источники вроде SQL или LDAP, если они настроены. Доступность сокета аутентификации Postfix имеет смысл проверять, когда проблема касается SMTP AUTH или взаимодействия Postfix с Dovecot; она не объясняет автоматически задержку IMAP-входа. Сначала сопоставляю протокол, сервис и лог, потом проверяю нужный сокет в 10-master.conf и права доступа. Чужой пример конфигурации может быть похожим, но локальные пути, имена пользователей и каталоги меняются от дистрибутива и способа установки.

• Не связывайте выбранный SASL-механизм со скоростью SQL.
• Проверяйте TLS и разрешенные способы входа вместе.
• Диагностируйте сокет Postfix только для соответствующего потока.

Порядок проверки и безопасное исправление

Мой порядок работы простой. Сначала фиксирую версию и итоговую конфигурацию по версии пакета и выводу doveconf -n, затем уточняю журнал и время одной попытки. Если команда или имя службы отличаются в сборке, сверяю их с документацией и пакетами именно этой системы. Дальше проверяю воспроизводимость на одной учетной записи: соединение установлено или нет, есть ли TLS, сколько занимает ответ на вход и начинает ли задержка появляться только при одновременных подключениях. Утренний пик стоит сравнивать с тихим периодом: иначе легко принять фоновую нагрузку за первопричину. Никакой параметр не меняю до того, как у меня есть наблюдаемый симптом, связанный с ним.

Если видно предупреждение о достигнутом лимите, проверяю границы служб и доступные ресурсы, а затем меняю только относящееся к нему значение, небольшим контролируемым шагом. Если задержка следует за ответом passdb/userdb, измеряю базу и конфигурацию запроса; только после этого рассматриваю auth_cache_* и его влияние на актуальность доступа. Если аутентификация проходит быстро, а клиент долго синхронизирует папки, разбираю IMAP-команды, индексы, хранилище и поведение самого клиента. Правку проверяю штатной проверкой конфигурации и журналом запуска, а результат сравниваю в одинаковом сценарии до и после. Иначе «стало быстрее» часто означает, что проверяли в другой момент и при другой нагрузке.

Кейс «Вереск-Сервис» в этой статье — условный сценарий для разбора, а не отчет о замере реального проекта. Поэтому я не приписываю ему время до и после, конкретный размер кэша или гарантированный результат для офиса на 50 человек. Для такого вывода нужны исходные журналы, версия, профиль нагрузки и повторяемый тест. Практический результат диагностики — установленный этап задержки, подтвержденная причина, безопасное изменение с планом отката и контрольный замер. Иногда этого достаточно, чтобы исправить конфигурацию; иногда обнаруживается узкое место в СУБД, дисках, сети или клиентской синхронизации. Честная диагностика заканчивается фактами, а не красивой цифрой в заголовке.

В заключении я сохраняю исходную конфигурацию, фиксирую примененные изменения и оставляю администратору короткий план контроля: за какими предупреждениями следить, как сравнить время входа и когда откатить правку. Для почтового сервера также проверяю, что изменения не нарушили доставку и авторизацию SMTP, если эти службы зависят от Dovecot. Отдельные параметры могут называться иначе или иметь иной синтаксис между версиями 2.3 и 2.4, поэтому документация должна совпадать с установленной веткой. Настроенный однажды лимит не отменяет наблюдения за нагрузкой: число устройств, фоновые подключения и почтовые клиенты со временем меняются.

• Зафиксируйте версию, конфигурацию и время теста.
• Сопоставьте симптом с конкретной службой.
• Меняйте один параметр и сравнивайте одинаковые сценарии.
• Сохраните откат и проверьте связанные почтовые службы.

Частые вопросы