Slow IMAP is a special kind of pain: users blame “the mail,” executives blame “the server,” and you end up staring at iostat at 2 a.m. wondering why opening a 12 KB message takes three seconds. Dovecot is usually not the villain. It’s the messenger delivering the truth about your storage, indexes, auth plumbing, and a handful of settings that decide whether Dovecot is a scalpel or a butter knife.
This is the field guide for fixing it without cargo-cult tuning. Seven settings matter disproportionately. The rest are mostly garnish. We’ll diagnose first, then tune, then verify with commands you can run right now.
Fast diagnosis playbook
If IMAP is slow, you don’t start by changing random Dovecot settings. You start by proving where latency comes from: auth, TLS, Dovecot indexes, mailbox storage, or the network. Here’s the fastest order of operations I’ve found that doesn’t waste your day.
1) Confirm what “slow” means (login, LIST, SELECT, FETCH, SEARCH)
- Slow login usually means auth backend latency, DNS, or TLS handshake behavior.
- Slow folder list points to namespace discovery, index problems, or storage metadata latency.
- Slow open/SELECT often means index rebuilds, fsync behavior, or high I/O latency.
- Slow FETCH body is almost always storage throughput/latency or mailbox format/pathology.
- Slow SEARCH is either no FTS (so it scans) or bad FTS (so it thrashes).
2) Check for global resource saturation
Before you blame Dovecot, check whether the box is drowning. If average I/O wait is high, Dovecot will look “slow” because it politely waits its turn.
3) Look for index churn or corruption symptoms
Index rebuilds can turn a healthy system into a sticky mess. You’ll see CPU, disk, and lots of index files being rewritten.
4) Validate the auth path and caches
If every IMAP connection triggers a slow LDAP/SQL request, you’ll experience “slow everything,” especially with short-lived mobile connections.
5) Validate concurrency and limits
Too few workers causes queues. Too many causes a thundering herd on storage. Both feel like “IMAP is slow.”
6) Only then touch settings (and change one thing at a time)
You want a clean causal chain: change → metric improves → no new failure mode.
Paraphrased idea (attributed): Werner Vogels (Amazon CTO) has long pushed the idea that you build for failure and measure everything—because reality doesn’t care about your assumptions.
Facts & context: why IMAP slowness looks weird
IMAP feels “slow” in ways HTTP-trained brains don’t expect. A few concrete facts help you reason about it instead of guessing.
- IMAP is chatty by design. Many clients do lots of small commands (LIST, STATUS, SELECT, FETCH headers) instead of one big request.
- Dovecot’s index strategy is a performance feature, not a nice-to-have. Without usable indexes, Dovecot has to touch mailbox files more often, and storage latency becomes user-visible.
- Maildir became popular because it was simple and avoided some locking problems. But “one file per message” can punish you on high-latency storage or with huge directory counts.
- mbox is older than your pager. It’s conceptually simple but can be painful with large files and locking; modern deployments rarely choose it for large-scale IMAP.
- Mobile clients changed the game. They reconnect often, creating bursts of short sessions that amplify auth and TLS costs.
- IMAP IDLE reduced polling but increased long-lived connections. That shifts pressure from “many connects” to “many concurrent sessions,” which stresses worker limits and memory.
- Filesystem metadata is often the bottleneck. Mail is lots of small files, stats, renames, and fsyncs; latency on metadata operations can dominate.
- Index files can be safer than you think. Dovecot’s index design is intended to be recoverable; the cost is that recovery (rebuild) is expensive when it happens at scale.
- Encryption and compliance pushed storage patterns. More servers now use encrypted filesystems or encrypted storage backends, which can introduce subtle latency spikes.
One of the reasons this topic is so annoying: you can have low CPU, plenty of RAM, and still deliver a terrible IMAP experience. That’s storage latency and per-operation overhead laughing at your dashboards.
Baseline first: measure where the time goes
We need a baseline. Not “users say it’s slow,” but “FETCH is 800 ms p95 and 2.2 s p99, correlated with 30 ms await on the mail volume.” Once you have that, you can tune with intent.
Decide what you’re optimizing
- Login latency (auth + TLS + process spawn)
- Folder open latency (index reads + mailbox metadata)
- Message list latency (index + cache)
- Message fetch latency (storage throughput + caching)
- Search latency (FTS vs brute force)
Then pick two measurement methods: one user-centric (IMAP timings) and one system-centric (I/O latency, CPU steal, queue depth). If you only look at one, you’ll fool yourself.
Joke #1: If your monitoring says “everything is green” while users are furious, congratulations—you’ve built a very reliable liar.
The 7 settings that actually matter
These are the knobs that regularly decide whether Dovecot feels snappy or sluggish. You’ll notice a theme: most “IMAP slowness” is storage behavior, index behavior, or auth behavior—expressed through Dovecot.
1) mail_location and your mailbox format choice
mail_location isn’t just a path. It’s a bet on I/O patterns.
- Maildir: lots of small files, heavy metadata, directory scaling issues, but predictable file-level corruption scope.
- mdbox/sdbox: Dovecot-native, optimized for performance and storage behavior, generally fewer filesystem objects, often better on high-latency or remote-ish storage.
When IMAP is “slow,” Maildir often translates that into “slow STAT(), slow open(), slow readdir(), slow fsync()” on a volume that was never sized for metadata IOPS. mdbox/sdbox often helps, but migrating formats is not a casual Tuesday change.
Opinion: If you’re operating at any meaningful scale and your storage is not extremely fast at metadata, strongly consider Dovecot’s native formats. If you’re small, Maildir is fine. If you’re medium and growing, Maildir will eventually send you an invoice.
Failure modes this setting influences
- Massive directory counts causing readdir/list latency.
- Backup/restore tools choking on “millions of tiny files.”
- Slow filesystem checks or snapshot operations.
2) Indexes: location and behavior (the real performance lever)
Indexes are where Dovecot earns its keep. Bad index placement turns your nice SSD into a sad SSD.
The settings that tend to matter in real life:
mail_index_path(or using per-mailbox default): where index files live.mail_index_log2_max_age: how long to keep transaction logs before compacting.mail_fsync/maildir_very_dirty_syncs(depending on format): impacts durability vs latency.
Practical advice: put indexes on the fastest low-latency storage you have. If you can’t, at least avoid placing them on the slowest tier. Index I/O is often small but latency-sensitive. Putting index I/O on high-latency storage is like running your database WAL on a USB stick.
Why index tuning works (and why it can hurt)
Indexes reduce mailbox file reads and accelerate common operations. But index churn can become its own workload. If you keep forcing rebuilds (corruption, permission problems, inode weirdness, NFS edge cases), “IMAP slow” becomes “IMAP is constantly rebuilding its brain.”
3) Process limits: Dovecot services, concurrency, and queues
Dovecot is a set of services: imap, imap-login, auth, etc. Concurrency controls are not just about “more is faster.” More can mean more parallel I/O and more lock contention.
Settings that matter most in production:
service imap { process_limit, service_count }service imap-login { process_limit }default_process_limit(global default)service anvil {}(connection tracking; indirectly impacts behavior under load)
Opinion: Don’t blindly raise process limits because “we have 32 cores.” IMAP load is usually I/O-limited. If you increase concurrency on an already-latency-bound storage layer, you can increase tail latency and make the user experience worse.
Failure modes
- Too low: login queues, “hanging” clients, periodic spikes.
- Too high: I/O amplification, lock contention, index contention, memory pressure.
4) Auth caching: stop paying for LDAP/SQL on every connection
Dovecot can authenticate against PAM, LDAP, SQL, or other backends. Many organizations build a beautiful centralized identity stack… then forget that mobile clients reconnect constantly and will happily DDoS your directory with legitimate logins.
Settings that matter:
auth_cache_sizeauth_cache_ttlauth_cache_negative_ttl
What you want: cache successful authentications long enough to smooth bursty reconnect behavior, but not so long you ignore password changes for hours. Cache negatives briefly to avoid brute-force amplification without locking out legit users for too long.
Warning: auth caching doesn’t fix slow LDAP/SQL; it hides it most of the time. Still fix the backend. But the cache is the difference between “a slow Tuesday” and “an incident.”
5) SSL/TLS settings that show up as “IMAP is slow”
Users call it “slow mail.” Your graphs show “CPU fine.” Meanwhile, every connection is doing expensive cryptography, certificate chain work, and sometimes DNS lookups for OCSP stapling or CRL checks in the wrong place.
Settings that matter:
ssl(required/yes/no)ssl_min_protocolssl_cipher_list(be careful)ssl_prefer_server_ciphersssl_options(session tickets behavior can matter by version)
Opinion: Don’t “optimize” TLS by forcing exotic cipher lists unless you know what you’re doing. Modern defaults are usually sane. The more common performance win is reducing reconnect frequency (client behavior) and ensuring you have enough imap-login capacity and CPU headroom for handshake bursts.
6) Full-text search: either do it right, or don’t pretend you have it
Search is where IMAP performance goes to die. Without FTS, clients doing server-side SEARCH can trigger brute-force scans across message bodies. With a misconfigured FTS backend, you get the same pain plus indexing overhead.
Settings that matter depend on your chosen backend, but the important part is the decision:
- Enable a real FTS backend and ensure it’s healthy and sized, or
- Accept that SEARCH is expensive and manage user expectations and client behavior.
Opinion: If you serve knowledge workers who live in search, invest in FTS properly. If you serve mostly “inbox triage” workflows, don’t introduce a fragile search subsystem just to say you have it.
7) Metrics/logging knobs: if you can’t time it, you can’t fix it
Dovecot can tell you what it’s doing. The trick is turning on the right visibility without setting your disks on fire with logs.
Settings and tools that matter in practice:
log_path,info_log_path,debug_log_path(use sparingly)auth_verbose(careful with privacy)mail_debug(temporary)stats/ metrics exporter integration (varies by deployment)
Opinion: Don’t run permanent debug logging in production unless you enjoy paying for disks and explaining why the incident timeline is missing because logrotate fell behind.
Three corporate mini-stories (anonymized, plausible, painfully familiar)
Mini-story 1: The incident caused by a wrong assumption
A mid-sized enterprise moved mail storage from local SSD to a network-attached filesystem. It was sold internally as “faster and more resilient,” because the storage array had impressive throughput numbers in a slide deck. Nobody asked about metadata latency or small-file workloads.
Within days, IMAP felt sticky: opening folders took seconds, and mobile clients would time out and reconnect, which made auth traffic spike, which made everything worse. The graphs looked odd: low CPU on the mail hosts, modest network usage, but elevated I/O wait in bursts.
The team’s first instinct was to increase Dovecot process limits. It seemed logical—more workers, more progress. In reality it increased parallel metadata ops on already-latency-bound storage, making tail latency worse. Users reported “sometimes it’s fine, sometimes it freezes,” the hallmark of queueing plus jitter.
The fix wasn’t magic. They relocated Dovecot indexes to local SSD while leaving message bodies on network storage, reduced concurrency to stop self-induced stampedes, and added auth caching to dampen reconnect storms. The big lesson: throughput benchmarks don’t predict IMAP performance; latency and metadata behavior do.
Mini-story 2: The optimization that backfired
A different organization saw slow SEARCH and decided to “speed it up” by enabling an FTS backend quickly, with minimal testing. They turned on indexing for everything, including giant shared mailboxes and automated journaling accounts that ingest high-volume mail.
For the first hour it looked like success. Searches returned quickly for a subset of users—because the index was warm for the accounts they tested. Then the indexer started catching up across the fleet. Disk I/O climbed, CPU climbed, and IMAP latencies started drifting upward.
The real problem was not that FTS is bad. It was that they treated indexing like a free add-on. They didn’t budget IOPS, they didn’t schedule initial indexing, and they didn’t isolate index storage from mailbox storage. They also didn’t cap indexing concurrency, so the indexer competed with live user traffic.
They ended up throttling indexing, isolating index files onto a faster tier, and excluding the pathological accounts from FTS. Search got better, and the system stopped melting. But it took an incident to learn that “turning on FTS” is a workload migration, not a checkbox.
Mini-story 3: The boring but correct practice that saved the day
A regulated business ran Dovecot on modest hardware but had a disciplined habit: every quarter they tested restoring a mailbox and they routinely ran integrity checks on a sample of accounts. Nothing heroic, just scheduled work and a runbook.
One week, users started complaining about slow folder opens and occasional “missing messages” in a few mailboxes. The on-call found elevated index rebuild messages in logs. Because they had baseline timings and known-good behavior, they quickly suspected index corruption or a filesystem issue rather than “random slowness.”
They used doveadm to force index rebuilds on affected mailboxes during a controlled window, verified filesystem health, and checked underlying storage latency. The incident stayed contained to a small set of users, and performance normalized after the rebuilds.
It wasn’t glamorous. No new tech. But the boring discipline—testing restores, keeping runbooks, and sampling mailbox health—meant they recognized the failure mode early and didn’t thrash around changing unrelated settings.
Common mistakes (symptom → root cause → fix)
This is the part where we stop pretending every environment is unique. These patterns repeat across companies because humans repeat across companies.
1) Symptom: login takes 2–10 seconds, then everything is fine
- Root cause: slow auth backend (LDAP/SQL), missing auth cache, or TLS handshake bursts saturating
imap-login. - Fix: enable
auth_cache_size/auth_cache_ttl, verify backend latency, increaseservice imap-login process_limitonly if CPU can handle it.
2) Symptom: opening folders is slow, but fetching a message body is okay
- Root cause: index I/O latency or index rebuilds; also common with high-latency metadata storage.
- Fix: move indexes to faster storage via
mail_index_path, investigate index corruption triggers, verify filesystem mount options and latency.
3) Symptom: LIST/STATUS is slow across many folders
- Root cause: too many mailboxes + expensive status lookups, client requesting STATUS for every folder, or namespace/mount latency.
- Fix: ensure indexes are healthy, consider client policy changes, avoid remote metadata-latency storage for Maildir-heavy workloads.
4) Symptom: SEARCH makes the server “freeze”
- Root cause: no FTS and brute-force scans; or FTS indexing competing with IMAP for I/O.
- Fix: either implement FTS properly (isolated storage, throttled indexing) or cap search behavior and set expectations.
5) Symptom: random spikes, p99 is terrible, averages look fine
- Root cause: storage jitter, queueing, too much concurrency, periodic index compaction/rebuild.
- Fix: measure I/O await and queue depth, right-size process limits, and address the storage layer first.
6) Symptom: it gets slower after “tuning” by increasing concurrency
- Root cause: you increased parallel I/O beyond what storage can serve with low latency.
- Fix: reduce worker counts; tune for latency, not maximum throughput; isolate indexes onto faster media.
Joke #2: Adding more IMAP processes to a slow disk is like adding more checkout lanes when you only have one cashier.
Practical tasks: commands, output meaning, and the decision you make
You wanted real tasks. Here are more than a dozen, each with a command, example output, what it means, and what you do next. Run them in order when you’re on-call and tired.
Task 1: Confirm Dovecot version and enabled components
cr0x@server:~$ dovecot --version
2.3.21 (a3c1c0a5b)
What it means: You’re on a 2.3.x line. Some tuning knobs and defaults differ by version.
Decision: Don’t apply advice written for 1.x/2.0 blindly. Keep your tuning within the version’s capabilities and defaults.
Task 2: Dump the effective configuration (not what you think you set)
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
What it means: You’re on Maildir, high process limits, and auth caching is off.
Decision: Flag this as “likely storage metadata pressure” plus “auth backend may be hot.” You now know what knobs are actually in effect.
Task 3: Check current connection counts and whether you’re queuing
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
What it means: Active sessions are visible. If this list is huge and stable, you have many concurrent connections (IDLE, mobile).
Decision: If connections are high, check process limits and memory. If users complain about logins during peaks, imap-login may be saturated.
Task 4: Check system load, iowait, and run queue quickly
cr0x@server:~$ uptime
12:44:19 up 31 days, 4:10, 2 users, load average: 14.22, 13.80, 11.95
What it means: Load is high. Load alone doesn’t prove CPU saturation; it includes tasks waiting on I/O.
Decision: Immediately check I/O wait and disk latency next. High load + low CPU usage often means I/O.
Task 5: Identify I/O latency and saturation (the usual culprit)
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
What it means: md0 is near-saturated (%util ~95) with high await (~36 ms). That’s user-visible latency for index/stat-heavy workloads.
Decision: Treat storage latency as priority #1. Reducing concurrency may improve tail latency immediately; longer-term fix is storage design.
Task 6: Spot filesystem-level latency issues and mount choices
cr0x@server:~$ findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS /var/mail
/dev/md0 /var/mail ext4 rw,relatime,data=ordered
What it means: ext4 with default-ish options. That’s fine, but not necessarily optimal for your mail pattern.
Decision: Don’t randomly change mount options in production to chase performance unless you understand durability impact. Instead, measure fsync cost and index churn first.
Task 7: Measure Dovecot process utilization and whether you’re forking too much
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
What it means: IMAP workers are active; login and auth also show CPU. If you see many short-lived processes, you may be handling reconnect storms.
Decision: If login/auth is high during user complaints, prioritize auth cache and backend latency investigation.
Task 8: Check for DNS issues affecting auth or TLS (quiet killer)
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
What it means: You have two DNS servers configured. If one is slow or dead, some lookups may stall.
Decision: If slow logins correlate with DNS timeouts in syslog, fix DNS first. Don’t tune Dovecot around broken plumbing.
Task 9: Check Dovecot logs for index rebuilds or corruption hints
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
What it means: Index rebuilds are happening under user load, and FTS locking is timing out. That will feel like slowness and “random” hangs.
Decision: Investigate why indexes are corrupting or locking. Consider relocating indexes, checking permissions, and assessing storage latency/locking semantics.
Task 10: Verify mailbox format and count files (Maildir pain check)
cr0x@server:~$ sudo -u vmail find /var/mail/vhosts/example.com/alice/Maildir -maxdepth 2 -type f | wc -l
186432
What it means: ~186k files for one user (including indexes, tmp, cur/new). That’s a lot of metadata.
Decision: If many users look like this and storage latency is non-trivial, Maildir will be a recurring performance problem. Consider mdbox/sdbox or index relocation and aggressive maintenance.
Task 11: Measure per-command IMAP timing from the server side (quick-and-dirty)
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
What it means: Opening INBOX took 412 ms from server perspective. That’s already in “user notices” territory.
Decision: Focus on index open cost and storage latency. If opens are slow, FETCH will be slow too, just with different symptoms.
Task 12: Inspect Dovecot index locations and sizes
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
What it means: Index cache is 50 MB for that mailbox. That’s not automatically bad, but it’s a lot of I/O if it’s constantly rewritten.
Decision: If indexes are on slow storage, move them. If corruption/rebuild happens, investigate underlying cause before changing cache sizes.
Task 13: Check backend auth latency (example with SQL; adapt to 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
What it means: ~482 ms to complete an auth test. That’s too slow if clients reconnect frequently.
Decision: Enable auth caching and fix backend performance (indexes in SQL, LDAP tuning, network path). If backend is remote, latency will show up as “IMAP slow.”
Task 14: Confirm whether you’re hitting file descriptor limits
cr0x@server:~$ sudo cat /proc/$(pidof dovecot | awk '{print $1}')/limits | grep -i "open files"
Max open files 1024 4096 files
What it means: Soft limit 1024 may be too low for a busy IMAP server with many concurrent connections and Maildir files.
Decision: Raise limits via systemd unit overrides or appropriate init config. If you hit limits, you’ll get failures and retries that look like slowness.
Task 15: Check whether the server is swapping (mail hates swapping)
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
What it means: You’re swapping. That turns “sometimes slow” into “everything is slow,” especially under connection bursts.
Decision: Reduce concurrency, add RAM, fix memory leaks, and stop swapping. If you must swap, you’re already in survival mode.
Task 16: Confirm whether IMAP is bottlenecked on TLS handshakes
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))
What it means: Many established connections sit on imap-login briefly during handshake/auth before they hand off.
Decision: If imap-login processes are pegged during peak, tune process_limit for imap-login and ensure CPU is available. Also reduce reconnection patterns if you can (client settings, load balancer behavior).
Checklists / step-by-step plan
Checklist A: “IMAP is slow right now” (30 minutes)
- Identify what’s slow: login vs LIST vs SELECT vs FETCH vs SEARCH (ask one affected user for exact behavior).
- Run
doveconf -nto capture effective settings (save output in the incident notes). - Check storage latency with
iostat -x. Ifawaitis high, stop tuning Dovecot and treat storage as the bottleneck. - Check Dovecot logs for index rebuild/corruption messages.
- Check auth latency with
doveadm auth testand enable auth caching if needed. - Check connection counts and
imap-loginsaturation (doveadm who,ss,ps). - If swapping: reduce concurrency, stop the bleeding, then plan capacity work.
Checklist B: Tuning without creating a new incident (1–2 days)
- Pick one target metric: p95 SELECT time, p95 login time, or SEARCH time for a representative mailbox.
- Move indexes to fast storage if currently co-located with slow mailbox storage. Validate permissions and backup strategy.
- Implement
auth_cache_sizeand sensible TTLs; validate password change behavior with stakeholders. - Right-size process limits: start conservative, then raise until latency stops improving.
- Decide on FTS strategy: implement properly or don’t. Avoid half-configured states.
- Verify results with the same commands and a consistent test mailbox.
Checklist C: Structural fixes (1–6 weeks)
- Evaluate mailbox format: if Maildir metadata is killing you, plan migration to mdbox/sdbox with a rollback plan.
- Fix storage: prioritize latency and metadata IOPS. Throughput numbers are not enough.
- Implement capacity management: file descriptor limits, memory sizing, and predictable concurrency.
- Establish maintenance windows for index rebuilds/fts reindexing to avoid daytime pain.
FAQ
1) Why is IMAP slow when CPU is low?
Because IMAP is often storage-latency bound. Low CPU with high iowait and high disk await is classic. Dovecot spends time waiting on filesystem metadata and index I/O.
2) Should I just increase service imap { process_limit }?
Only if you’ve proven you’re CPU-bound or queue-bound on the Dovecot side. If storage latency is the bottleneck, more workers can worsen tail latency by increasing parallel I/O contention.
3) Is Maildir inherently slow?
No. Maildir can be fast on low-latency local storage with good metadata performance. It becomes slow when you scale file counts, use high-latency storage, or create huge folder hierarchies that amplify metadata operations.
4) What’s the single best improvement for folder-open latency?
Healthy indexes on fast storage. That often means relocating index files (via mail_index_path) and stopping the underlying cause of rebuilds.
5) Do I need FTS?
If users rely on server-side search across bodies and attachments, yes—implement it properly. If searches are rare, FTS can become extra moving parts and extra I/O for limited benefit.
6) Why do mobile clients make everything worse?
They reconnect frequently, which amplifies login/auth/TLS costs and increases concurrency churn. Without auth caching and adequate imap-login capacity, you get periodic “mail is slow” storms.
7) How do I know if indexes are corrupting?
Logs will mention rebuilding index files or corrupted cache/index files. Users may see slow folder opens and inconsistent message lists. Confirm via log review and targeted doveadm operations.
8) Can TLS settings really cause IMAP slowness?
Yes, especially if you have connection storms or under-provisioned imap-login workers. TLS handshake cost becomes visible when multiplied by lots of reconnects.
9) What if SEARCH is slow but everything else is fine?
That’s usually “no FTS” or “FTS not keeping up.” Decide whether to invest in search indexing. Otherwise, SEARCH will remain an expensive operation by design.
Next steps you can execute this week
- Run the fast diagnosis playbook and capture evidence:
doveconf -n,iostat -x, relevant log excerpts, and one timeddoveadm fetchtest. - If storage latency is high, treat it as the root problem. Reduce concurrency to lower contention and start a plan to move indexes to faster media.
- Enable auth caching if you have any remote auth backend and any meaningful mobile population. Tune TTLs so you don’t surprise security teams.
- Right-size process limits with data: increase until latency stops improving, then stop. “Maximizing” workers is how you maximize incidents.
- Make a clear search decision: implement FTS properly (isolated resources, controlled indexing), or accept slower SEARCH and avoid destabilizing the system.
- Add guardrails: file descriptor limits, swap avoidance, and lightweight metrics that tell you whether you’re auth-bound, index-bound, or storage-bound.
If you do only one thing: measure I/O latency and index health before changing settings. Most Dovecot “performance tuning” is actually storage engineering and operational discipline wearing a mail-shaped hat.