Dovecot: IMAP працює повільно — 7 налаштувань, що справді мають значення

Швидкий план діагностики

Якщо IMAP повільний, не починайте зі зміни випадкових налаштувань Dovecot. Почніть із доведення, звідки береться затримка: авторизація, TLS, індекси Dovecot, зберігання пошти чи мережа. Ось найшвидший порядок дій, який я знаходив і який не витрачає ваш день марно.

1) Підтвердьте, що означає «повільно» (логін, LIST, SELECT, FETCH, SEARCH)

• Повільний логін зазвичай означає латентність бекенду авторизації, DNS або поведінку TLS-рукостискання.
• Повільний перелік папок вказує на виявлення просторів імен, проблеми з індексами або латентність метаданих сховища.
• Повільне відкриття/SELECT часто означає перебудову індексів, поведінку fsync або високу I/O-латентність.
• Повільний FETCH body майже завжди пов’язаний з пропускною здатністю/латентністю сховища або патологією формату поштової скриньки.
• Повільний SEARCH — або немає FTS (тому виконується сканування), або погано налаштований FTS (тоді він «шатуна»).

2) Перевірте глобальне навантаження ресурсів

Перш ніж звинувачувати Dovecot, перевірте, чи сервер не тоне в навантаженні. Якщо середній I/O wait високий, Dovecot буде виглядати «повільним», бо він чемно чекає своєї черги.

3) Шукайте ознаки зриву або корупції індексів

Перебудови індексів можуть перетворити здорову систему на липку кашу. Ви побачите CPU, диск і багато файлів індексів, які переписуються.

4) Перевірте шлях авторизації та кеші

Якщо кожне IMAP-з’єднання викликає повільний LDAP/SQL-запит, ви відчуєте «все повільно», особливо при короткоживучих мобільних підключеннях.

5) Перевірте паралелізм і ліміти

Замало воркерів викликає черги. Забагато — спричиняє «гуркітну зграю» на сховищі. Обидва випадки відчуваються як «IMAP повільний».

6) Лише потім торкайтеся налаштувань (і змініть лише одну річ одночасно)

Вам потрібний чистий причинно-наслідковий ланцюг: зміна → метрика покращується → немає нового режиму відмови.

Парафразована ідея (приписано): Werner Vogels (CTO Amazon) давно просував думку: проєктуйте для відмов і вимірюйте все — бо реальність не дбає про ваші припущення.

Факти й контекст: чому повільний IMAP виглядає дивно

IMAP відчувається «повільним» так, як мозок, звиклий до HTTP, цього не очікує. Кілька конкретних фактів допоможуть вам міркувати замість гадань.

1. IMAP за дизайном дуже розмовний. Багато клієнтів виконують багато малих команд (LIST, STATUS, SELECT, FETCH headers) замість одного великого запиту.
2. Стратегія індексів Dovecot — це функція продуктивності, а не «приємна додаткова можливість». Без корисних індексів Dovecot змушений частіше торкатися файлів поштової скриньки, і латентність сховища стає помітною для користувача.
3. Maildir став популярним через простоту і менші проблеми з блокуванням. Але «один файл на повідомлення» може карати вас на сховищі з високою латентністю або при величезній кількості файлів у директорії.
4. mbox старший за ваш пейджер. Він концептуально простий, але може бути болісним при великих файлах і блокуваннях; сучасні великі розгортання рідко обирають його.
5. Мобільні клієнти змінили правила гри. Вони часто перепідключаються, створюючи сплески коротких сесій, що підсилює витрати на авторизацію і TLS.
6. IMAP IDLE зменшив опитування, але збільшив довготривалі підключення. Це змістило тиск з «багато підключень» до «багато одночасних сесій», що навантажує ліміти воркерів і пам’ять.
7. Метадані файлової системи часто є вузьким місцем. Пошта — це багато маленьких файлів, stat, rename та fsync; латентність операцій з метаданими може домінувати.
8. Файли індексів можуть бути безпечнішими, ніж ви думаєте. Дизайн індексів Dovecot передбачає відновлюваність; плата — дорога перебудова (rebuild) у масштабі.
9. Шифрування та вимоги відповідності змусили змінити сховище. Більше серверів тепер використовують зашифровані файлові системи або бекенди, що може вводити тонкі сплески латентності.

Одна з причин, чому ця тема така дратівлива: у вас може бути низький CPU, багато RAM, але жахливий IMAP-досвід. Це сміх над вашими дашбордами від латентності сховища та витрат на операцію.

Спочатку базова лінія: виміряйте, куди йде час

Потрібна базова лінія. Не «користувачі кажуть, що повільно», а «FETCH — 800 ms p95 і 2.2 s p99, корелюється з 30 ms await на томі пошти». Коли у вас це є, ви можете налаштовувати з наміром.

Вирішіть, що ви оптимізуєте

• Затримка логіну (авторизація + TLS + створення процесу)
• Затримка відкриття папки (читання індексів + метадані поштової скриньки)
• Затримка списку повідомлень (індекс + кеш)
• Затримка отримання повідомлення (пропускна здатність сховища + кешування)
• Затримка пошуку (FTS проти грубого сканування)

Потім виберіть два методи вимірювання: один орієнтований на користувача (таймінги IMAP), інший — орієнтований на систему (латентність I/O, CPU steal, глибина черги). Якщо дивитися лише на один, ви себе обдурите.

Жарт №1: Якщо ваш моніторинг каже «все зелене», а користувачі в люті — вітаю, ви побудували дуже надійного брехуна.

7 налаштувань, що справді мають значення

Ось ті ручки, що регулярно визначають, чи відчувається Dovecot швидким або повільним. Ви помітите тему: більшість «повільності IMAP» — це поведінка сховища, індексів або авторизації — виражена через Dovecot.

Три корпоративні міні-історії (анонімізовані, правдоподібні, болісно знайомі)

Міні-історія 1: Інцидент через неправильне припущення

Підприємство середнього розміру перенесло зберігання пошти з локального SSD на мережеву файлову систему. Це продавалося як «швидше й більш стійке», бо масив мав вражаючі показники пропускної здатності в презентації. Ніхто не запитав про латентність метаданих або навантаження на роботу з багатьма маленькими файлами.

Через кілька днів IMAP став липким: відкриття папок займало секунди, мобільні клієнти таймаутили й перепідключалися, що спричиняло сплески авторизації і погіршувало ситуацію. Графіки виглядали дивно: низький CPU на поштових хостах, помірне використання мережі, але підвищений I/O wait у сплесках.

Перший інстинкт команди — підвищити ліміти процесів Dovecot. Здавалося логічним: більше воркерів — більше прогресу. Насправді це збільшило паралельні операції над метаданими на вже латентному сховищі й погіршило хвилі затримок. Користувачі повідомляли «інколи нормально, інколи зависає» — типова ознака чергування плюс джиттер.

Рішення не було магічним. Вони перемістили індекси Dovecot на локальний SSD, лишивши тіла повідомлень на мережевому сховищі, зменшили паралелізм щоб зупинити самостійно спричинені штампи, і додали кеш авторизації щоб загасити бурі перепідключень. Великий урок: бенчмарки пропускної здатності не прогнозують продуктивність IMAP; латентність і поведінка метаданих — так.

Міні-історія 2: Оптимізація, що відкотилася

Інша організація помітила повільний SEARCH і вирішила «прискорити» його, швидко ввімкнувши FTS-бекенд без ретельного тестування. Вони включили індексацію для всього, включно з гігантськими спільними скриньками та обліками журналювання, що інтенсивно інжестять пошту.

Першу годину це виглядало як успіх. Пошуки швидко повертали результати для підмножини користувачів — бо індекс був «теплий» для тестованих обліків. Потім індексатор почав наздоганяти весь парк. Диск I/O підскочив, CPU піднявся, і затримки IMAP почали зростати.

Проблема не в тому, що FTS поганий. Проблема в тому, що вони сприйняли індексацію як безкоштовний додаток. Вони не виділили IOPS, не спланували початкову індексацію та не ізолювали зберігання індексів від зберігання пошти. Також вони не обмежили паралелізм індексації, тож індексатор змагався з живим користувацьким трафіком.

Вони врешті загальмували індексацію, ізолювали файли індексів на швидшому рівні й виключили патологічні обліки з FTS. Пошук став кращим, а система перестала «плавитись». Але інцидент показав: «увімкнути FTS» — це міграція робочого навантаження, а не просто галочка.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Одна регульована компанія запускала Dovecot на скромному обладнанні, але мала дисципліну: кожного кварталу вони тестували відновлення пошт і регулярно запускали перевірки цілісності на вибірці обліків. Нічого героїчного, просто запланована робота і рукопис процедури.

І от одного тижня користувачі почали скаржитися на повільне відкриття папок і випадкові «відсутні повідомлення» в кількох скриньках. На чергуванні побачили підвищену кількість повідомлень про перебудову індексів у логах. Оскільки у них були базові таймінги й відомі хороші показники, вони швидко запідозрили корупцію індексів або проблему файлової системи, а не «випадкову повільність».

Вони використали doveadm, щоб примусово перебудувати індекси для уражених скриньок під керованим вікном обслуговування, перевірили здоров’я файлової системи й латентність сховища. Інцидент залишився локалізованим, і продуктивність нормалізувалася після перебудов.

Це не було романтично. Ніякої нової технології. Але сумна дисципліна — тестувати відновлення, мати рукопис процедури, і вибірково перевіряти здоров’я скриньок — дозволила їм у ранній стадії впізнати режим відмов і не метушитися зі зміною нерелевантних налаштувань.

Типові помилки (симптом → корінна причина → виправлення)

Тут ми припиняємо вдавати, що кожне середовище унікальне. Ці патерни повторюються через те, що люди повторюються між компаніями.

1) Симптом: логін займає 2–10 секунд, а потім все добре

• Корінна причина: повільний бекенд авторизації (LDAP/SQL), відсутній кеш авторизації або сплески TLS-рукостискань, що насичують imap-login.
• Виправлення: увімкніть auth_cache_size/auth_cache_ttl, перевірте латентність бекенду, підвищуйте service imap-login process_limit лише якщо CPU витримає.

2) Симптом: відкриття папок повільне, але отримання тіла повідомлення в порядку

• Корінна причина: латентність I/O індексів або перебудови індексів; також часто з’являється на сховищах з високою латентністю метаданих.
• Виправлення: перемістіть індекси на швидше сховище через mail_index_path, дослідіть тригери корупції індексів, перевірте опції монтування та латентність файлової системи.

3) Симптом: LIST/STATUS повільні по багатьох папках

• Корінна причина: занадто багато пошт.скриньок + дорогі запити STATUS, клієнт запитує STATUS для кожної папки, або латентність namespace/mount.
• Виправлення: переконайтеся, що індекси здорові, розгляньте політику клієнта, уникайте віддаленого сховища з високою латентністю для робочих навантажень з великою кількістю Maildir-файлів.

4) Симптом: SEARCH «заморожує» сервер

• Корінна причина: немає FTS і виконуються грубі сканування; або індексація FTS конкурує з IMAP за I/O.
• Виправлення: або реалізуйте FTS правильно (ізольоване сховище, обмежена індексація), або обмежте поведінку пошуку і встановіть очікування.

5) Симптом: випадкові сплески, p99 жахливий, середні значення в нормі

• Корінна причина: джиттер сховища, чергування, надмірна паралельність, періодична компакція/перебудова індексів.
• Виправлення: виміряйте I/O await і глибину черги, правильно налаштуйте ліміти процесів і спочатку вирішіть проблему зі сховищем.

6) Симптом: після «тюнінгу» збільшенням паралельності стало гірше

• Корінна причина: ви збільшили паралельний I/O понад можливості сховища для обслуговування з низькою латентністю.
• Виправлення: зменшіть кількість воркерів; налаштовуйте для низької латентності, а не для максимальної пропускної здатності; ізолюйте індекси на швидшому медіа.

Жарт №2: Додавати більше IMAP-процесів до повільного диска — це як додавати більше кас, коли у вас тільки один касир.

Практичні завдання: команди, значення виводу та рішення

Ви хотіли реальні завдання. Ось більше десятка, кожне з командою, прикладом виводу, що це значить та що робити далі. Виконуйте їх у порядку, коли ви на чергуванні і втомлені.

Завдання 1: Підтвердьте версію Dovecot і ввімкнені компоненти

cr0x@server:~$ dovecot --version
2.3.21 (a3c1c0a5b)

Що це означає: Ви на гілці 2.3.x. Деякі налаштувальні ручки й дефолти відрізняються за версіями.

Рішення: Не застосовуйте поради, написані для 1.x/2.0 бездумно. Тримайте тюнінг у межах можливостей і дефолтів вашої версії.

Завдання 2: Злити ефективну конфігурацію (не те, що ви думаєте, що налаштували)

cr0x@server:~$ doveconf -n
mail_location = maildir:~/Maildir
protocols = imap lmtp
service imap-login { process_limit = 64 }
service imap { process_limit = 256 }
auth_cache_size = 0
ssl = required

Що це означає: У вас Maildir, високі ліміти процесів і кеш авторизації вимкнений.

Рішення: Позначте це як «ймовірний тиск на метадані сховища» плюс «бекенд авторизації може бути гарячим». Тепер ви знаєте, які ручки реально діють.

Завдання 3: Перевірте поточну кількість з’єднань і чи є черги

cr0x@server:~$ doveadm who
username          service  proto  pid  ip
alice@example.com imap     imap   2213 10.10.5.21
bob@example.com   imap     imap   3371 10.10.6.18

Що це означає: Активні сесії видимі. Якщо цей список великий і стабільний — у вас багато одночасних з’єднань (IDLE, мобільні).

Рішення: Якщо з’єднань багато, перевірте ліміти процесів і пам’ять. Якщо користувачі скаржаться на логіни під час піків — imap-login може бути насичений.

Завдання 4: Швидко перевірте системне навантаження, iowait і чергу запуску

cr0x@server:~$ uptime
 12:44:19 up 31 days,  4:10,  2 users,  load average: 14.22, 13.80, 11.95

Що це означає: Навантаження високе. Саме по собі навантаження не доводить перевантаження CPU; воно включає задачі, що чекають на I/O.

Рішення: Негайно перевірте I/O wait і латентність диска. Високе навантаження з низьким використанням CPU часто означає I/O.

Завдання 5: Визначте латентність I/O і насичення (звичайний винуватець)

cr0x@server:~$ iostat -x 1 3
Linux 6.1.0 (server)  02/04/2026  _x86_64_  (16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.12    0.00    3.01   28.55    0.00   62.32

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
nvme0n1         220.0   310.0  9800.0 15400.0   2.1   0.3   18.0
md0             180.0   290.0  8200.0 14800.0  35.8   0.6   95.0

Що це означає: md0 майже насичений (%util ~95) з високим await (~36 ms). Це затримка, помітна користувачеві для навантажень, що чутливі до індекс/стат-операцій.

Рішення: Розглядайте латентність сховища як пріоритет №1. Зменшення паралелізму може негайно поліпшити хвости затримок; довгострокове рішення — дизайн сховища.

Завдання 6: Помітити проблеми на рівні ФС і вибір монтування

cr0x@server:~$ findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS /var/mail
/dev/md0 /var/mail ext4 rw,relatime,data=ordered

Що це означає: ext4 з опціями близькими до дефолтних. Це нормально, але не обов’язково оптимально для вашого патерну пошти.

Рішення: Не змінюйте опції монтування в продакшні випадково, гоняючись за продуктивністю, якщо не розумієте наслідків для надійності. Краще виміряти вартість fsync і індексну хаотичність спочатку.

Завдання 7: Виміряйте використання процесів Dovecot і чи занадто часто ви форкаєтесь

cr0x@server:~$ ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head
 4412 imap        12.5  0.7
 4471 imap        11.8  0.6
 1921 imap-login   6.2  0.2
 1760 auth         3.1  0.1

Що це означає: IMAP-воркери активні; login і auth також показують CPU. Якщо ви бачите багато короткоживучих процесів — можливо, маєте справу зі штормом перепідключень.

Рішення: Якщо login/auth високі під час скарг користувачів — пріоритет кеш авторизації та дослідження латентності бекенду.

Завдання 8: Перевірте проблеми DNS, що впливають на авторизацію або TLS (тихий вбивця)

cr0x@server:~$ resolvectl status | sed -n '1,25p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.10.0.53
DNS Servers: 10.10.0.53 10.10.0.54

Що це означає: У вас налаштовано два DNS-сервери. Якщо один повільний або мертвий, деякі запити можуть застрягнути.

Рішення: Якщо повільні логіни корелюються з тайм-аутами DNS у syslog — спочатку виправте DNS. Не налаштовуйте Dovecot навколо зламаної інфраструктури.

Завдання 9: Перевірте логи Dovecot на перебудови індексів або підказки про корупцію

cr0x@server:~$ journalctl -u dovecot --since "1 hour ago" | tail -n 12
Feb 04 12:10:31 server dovecot[4412]: imap(alice@example.com): Warning: Mailbox INBOX: Rebuilding index files
Feb 04 12:10:32 server dovecot[4412]: imap(alice@example.com): Warning: fts: Indexes disabled for mailbox INBOX: lock timed out
Feb 04 12:10:40 server dovecot[4471]: imap(bob@example.com): Warning: Mailbox Archive: Corrupted index cache file, re-building

Що це означає: Перебудови індексів відбуваються під навантаженням користувачів, і блокування FTS таймаутять. Це відчувається як повільність і «випадкові» зависання.

Рішення: Дослідіть, чому індекси корумпуються або блокуются. Розгляньте переміщення індексів, перевірку прав і оцінку латентності/семантики блокувань сховища.

Завдання 10: Підтвердьте формат поштової скриньки і порахуйте файли (перевірка болю Maildir)

cr0x@server:~$ sudo -u vmail find /var/mail/vhosts/example.com/alice/Maildir -maxdepth 2 -type f | wc -l
186432

Що це означає: ~186k файлів для одного користувача (включно з індексами, tmp, cur/new). Це багато метаданих.

Рішення: Якщо багато користувачів мають таку картину і латентність сховища непроста — Maildir буде повторюваною проблемою продуктивності. Розгляньте mdbox/sdbox або переміщення індексів і агресивне обслуговування.

Завдання 11: Виміряйте часи команд IMAP з боку сервера (швидко і грубо)

cr0x@server:~$ sudo doveadm -D -o mail_debug=yes fetch -u alice@example.com hdr.subject mailbox INBOX guid 1 2>&1 | tail -n 12
doveadm(alice@example.com): Debug: Loading modules from directory: /usr/lib/dovecot/modules
doveadm(alice@example.com): Debug: Opening mailbox INBOX
doveadm(alice@example.com): Debug: Mailbox INBOX: Opened in 412 msecs
doveadm(alice@example.com): Debug: Fetching mails: 1

Що це означає: Відкриття INBOX зайняло 412 ms з боку сервера. Це вже в зоні, яку помічає користувач.

Рішення: Зосередьтеся на вартості відкриття індексу й латентності сховища. Якщо відкриття повільне, FETCH теж буде повільним, лише з іншими симптомами.

Завдання 12: Перегляньте розташування і розміри індексів Dovecot

cr0x@server:~$ sudo -u vmail find /var/mail/vhosts/example.com/alice/Maildir -maxdepth 1 -name 'dovecot*' -type f -printf '%f %s\n' | head
dovecot.index 10485760
dovecot.index.cache 52428800
dovecot.index.log 2097152

Що це означає: Кеш індексу 50 MB для тієї скриньки. Це не завжди погано, але це багато I/O, якщо він постійно переписується.

Рішення: Якщо індекси на повільному сховищі — перемістіть їх. Якщо відбуваються корупції/перебудови, дослідіть підставу перед зміною розмірів кешу.

Завдання 13: Перевірте латентність бекенду авторизації (приклад із SQL; адаптуйте для LDAP)

cr0x@server:~$ time sudo -u dovecot doveadm auth test alice@example.com 'correcthorsebatterystaple'
passdb: alice@example.com auth succeeded
extra fields:
  user=alice@example.com

real    0m0.482s
user    0m0.015s
sys     0m0.010s

Що це означає: ~482 ms на тест авторизації. Це занадто повільно, якщо клієнти часто перепідключаються.

Рішення: Увімкніть кеш авторизації і виправте продуктивність бекенду (індекси в SQL, налаштування LDAP, мережевий шлях). Якщо бекенд віддалений — латентність проявиться як «IMAP повільний».

Завдання 14: Підтвердьте, чи не досягаєте лімітів дескрипторів файлів

cr0x@server:~$ sudo cat /proc/$(pidof dovecot | awk '{print $1}')/limits | grep -i "open files"
Max open files            1024                 4096                 files

Що це означає: Soft limit 1024 може бути замалим для насиченого IMAP-сервера з багатьма одночасними підключеннями і Maildir-файлами.

Рішення: Підвищте ліміти через systemd override або відповідну ініціалізаційну конфігурацію. Якщо ви досягаєте лімітів — будуть помилки й повторні спроби, що виглядає як повільність.

Завдання 15: Перевірте, чи відбувається свопінг (пошта ненавидить своп)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi        28Gi       600Mi       1.2Gi       2.4Gi       1.4Gi
Swap:           4Gi        2.9Gi       1.1Gi

Що це означає: У вас відбувається свопінг. Це перетворює «іноді повільно» на «все повільно», особливо під час сплесків підключень.

Рішення: Зменшіть паралелізм, додайте RAM, виправте витоки пам’яті і припиніть свопінг. Якщо змушені свопитись — ви вже в режимі виживання.

Завдання 16: Підтвердьте, чи IMAP звужений коштами TLS-рукостискань

cr0x@server:~$ sudo ss -tanp | grep ':993' | head
ESTAB 0 0 10.10.1.10:993 10.10.5.21:54402 users:(("imap-login",pid=1921,fd=11))
ESTAB 0 0 10.10.1.10:993 10.10.6.18:53177 users:(("imap-login",pid=1921,fd=12))

Що це означає: Багато встановлених з’єднань сидять на imap-login коротко під час рукостискання/auth, перед передачою у воркери.

Рішення: Якщо imap-login процеси завантажені під час піків — налаштуйте process_limit для imap-login і забезпечте CPU-резерв. Також зменште шаблони перепідключень (налаштування клієнтів, поведінка балансувальника), якщо це можливо.

Контрольні списки / поетапний план

Контрольний список A: «IMAP повільний зараз» (30 хвилин)

1. Визначте, що саме повільне: логін vs LIST vs SELECT vs FETCH vs SEARCH (запитайте у одного постраждалого користувача точну поведінку).
2. Запустіть doveconf -n, щоб зафіксувати ефективні налаштування (збережіть вивід в нотатках інциденту).
3. Перевірте латентність сховища за допомогою iostat -x. Якщо await високий — припиніть налаштовувати Dovecot і вважайте сховище вузьким місцем.
4. Перегляньте логи Dovecot на предмет перебудов/корупції індексів.
5. Перевірте латентність авторизації за допомогою doveadm auth test і увімкніть кеш авторизації при потребі.
6. Перевірте кількість підключень і насичення imap-login (doveadm who, ss, ps).
7. Якщо відбувається свопінг: зменшіть паралелізм, зупиніть кровотечу, а потім плануйте збільшення потужності.

Контрольний список B: Налаштування без створення нового інциденту (1–2 дні)

1. Виберіть одну цільову метрику: p95 SELECT time, p95 login time або SEARCH time для репрезентативної скриньки.
2. Перемістіть індекси на швидке сховище, якщо вони зараз розташовані разом з повільними даними. Перевірте права й стратегію резервного копіювання.
3. Реалізуйте auth_cache_size і розумні TTL; узгодьте поведінку при зміні паролів зі стейкхолдерами.
4. Підійміть ліміти процесів правильно: почніть консервативно, потім збільшуйте, доки затримка не перестане покращуватися.
5. Прийміть рішення щодо FTS: впроваджуйте правильно або не впроваджуйте. Уникайте напівналаштованих станів.
6. Перевірте результати тими ж командами й на тій самій тестовій скриньці для консистентності.

Контрольний список C: Структурні виправлення (1–6 тижнів)

1. Оцініть формат поштових скриньок: якщо Maildir вбиває вас метаданими — заплануйте міграцію на mdbox/sdbox з планом відкату.
2. Виправте сховище: пріоритет — латентність і IOPS метаданих. Показники пропускної здатності самі по собі недостатні.
3. Впровадьте управління ємністю: ліміти дескрипторів, розміри пам’яті і передбачений паралелізм.
4. Встановіть вікна обслуговування для перебудов індексів/реіндексації FTS, щоб уникнути болю в робочий час.

Поширені запитання

1) Чому IMAP повільний, коли CPU низький?

Бо IMAP часто обмежений латентністю сховища. Низький CPU з високим iowait і великим await диска — класика. Dovecot чекає на файлові метадані й I/O індексів.

2) Чи просто підвищити service imap { process_limit }?

Тільки якщо ви довели, що вузьке місце — CPU або черга на боці Dovecot. Якщо вузьке місце — латентність сховища, більше воркерів може погіршити кінцеві затримки, підвищуючи паралельний I/O.

3) Чи Maildir за своєю суттю повільний?

Ні. Maildir може бути швидким на низьколатентному локальному сховищі з доброю роботою з метаданими. Він стає повільним при масштабуванні кількості файлів, на сховищі з високою латентністю або при величезних ієрархіях папок, що посилює операції з метаданими.

4) Яке одне найкраще покращення для затримки відкриття папки?

Здорові індекси на швидкому сховищі. Це часто означає переміщення файлів індексів (через mail_index_path) і припинення причин перебудов.

5) Чи потрібен мені FTS?

Якщо користувачі покладаються на серверний пошук по тілам і вкладеннях — так, реалізуйте його правильно. Якщо пошуки рідкісні — FTS може стати додатковим крихким компонентом і додатковим I/O з обмеженою користю.

6) Чому мобільні клієнти все ускладнюють?

Вони часто перепідключаються, що підсилює витрати на логін/авторизацію/TLS і створює хвилі паралельності. Без кешу авторизації і достатньої потужності imap-login ви отримаєте періодичні «поштова хвиля повільна» шторми.

7) Як дізнатися, що індекси корумпуються?

Логи будуть містити повідомлення про перебудову індексів або пошкоджені файли cache/index. Користувачі можуть бачити повільні відкриття папок і непослідовні списки повідомлень. Підтвердіть через перегляд логів і цілеспрямовані операції doveadm.

8) Чи можуть TLS-настройки справді викликати повільний IMAP?

Так, особливо при штормах з’єднань або недостатньо потужних imap-login воркерах. Вартість TLS-рукостискання помітна, коли помножена на багато перепідключень.

9) Що робити, якщо SEARCH повільний, але все інше нормальне?

Зазвичай це «немає FTS» або «FTS не встигає». Прийміть рішення інвестувати в індексацію пошуку або ж погодьтеся з тим, що SEARCH залишатиметься дорогою операцією за дизайном.

Наступні кроки, які ви можете виконати цього тижня

1. Запустіть швидкий план діагностики і зафіксуйте докази: doveconf -n, iostat -x, відповідні уривки логів і один тестовий doveadm fetch з таймінгом.
2. Якщо латентність сховища висока — вважайте це кореневою проблемою. Зменшіть паралелізм, щоб знизити конкуренцію, і почніть план переміщення індексів на швидше медіа.
3. Увімкніть кеш авторизації, якщо у вас будь-який віддалений бекенд авторизації і значуща мобільна популяція. Налаштуйте TTL, щоб не здивувати команди безпеки.
4. Підійміть ліміти процесів розумно з даними: збільшуйте, поки затримка перестає покращуватись, і зупиняйтесь. «Максимізація» воркерів — якраз шлях до максимуму інцидентів.
5. Прийміть чітке рішення по пошуку: впровадьте FTS правильно (ізольовані ресурси, контрольована індексація) або прийміть повільніший SEARCH і уникайте дестабілізації системи.
6. Додайте запобіжники: ліміти дескрипторів файлів, уникнення свопу і легкі метрики, що покажуть, чи ви обмежені авторизацією, індексами чи сховищем.

Якщо зробити лише одну річ: виміряйте латентність I/O і стан індексів перед зміною налаштувань. Більшість «тюнінгу продуктивності» Dovecot — фактично інженерія сховища та операційна дисципліна, запакована в поштову обгортку.