Dovecot : IMAP lent — les 7 réglages qui comptent vraiment

février 20, 2026 • février 20, 2026 • Lecture : 29 min • Views: 0

Cet article vous a aidé ?

Un IMAP lent est une douleur particulière : les utilisateurs accusent « le mail », les dirigeants accusent « le serveur », et vous vous retrouvez à scruter iostat à 2 h du matin en vous demandant pourquoi l’ouverture d’un message de 12 KB prend trois secondes. Dovecot n’est généralement pas le coupable. Il fait remonter la vérité sur votre stockage, vos index, votre chaîne d’authentification et une poignée de réglages qui décident si Dovecot est un scalpel ou un couteau à beurre.

Voici le guide de terrain pour réparer tout ça sans réglages magiques. Sept réglages comptent de manière disproportionnée. Le reste est surtout de l’ornement. Nous diagnostiquerons d’abord, puis nous ajusterons, puis nous vérifierons avec des commandes que vous pouvez lancer tout de suite.

Plan d’intervention rapide

Si IMAP est lent, vous ne commencez pas par modifier des réglages Dovecot au hasard. Vous commencez par prouver d’où vient la latence : auth, TLS, index Dovecot, stockage des boîtes ou réseau. Voici l’ordre d’action le plus rapide que j’ai trouvé et qui ne vous fera pas perdre la journée.

1) Confirmez ce que « lent » signifie (login, LIST, SELECT, FETCH, SEARCH)

Login lent signifie généralement latence du backend d’auth, DNS ou comportement de la poignée de main TLS.
Liste de dossiers lente pointe vers la découverte des namespaces, des problèmes d’index, ou la latence des métadonnées de stockage.
Ouverture/SELECT lente signifie souvent reconstructions d’index, comportement d’fsync, ou forte latence d’E/S.
FETCH du corps lent est presque toujours débit/latence de stockage ou pathologie/format de la boîte aux lettres.
SEARCH lent est soit absence de FTS (donc balayage), soit FTS mal configuré (donc thrashing).

2) Vérifiez la saturation globale des ressources

Avant d’accuser Dovecot, vérifiez si la machine est noyée. Si le taux d’attente I/O moyen est élevé, Dovecot paraîtra « lent » parce qu’il attend poliment son tour.

3) Cherchez les signes de churn ou corruption d’index

Les reconstructions d’index peuvent transformer un système sain en désordre collant. Vous verrez CPU, disque et beaucoup de fichiers d’index réécrits.

4) Validez la chaîne d’auth et les caches

Si chaque connexion IMAP déclenche une requête LDAP/SQL lente, vous vivrez un « tout lent », surtout avec des connexions mobiles courtes.

5) Validez la concurrence et les limites

Trop peu de workers provoque des files d’attente. Trop en provoque un « thundering herd » sur le stockage. Les deux donnent l’impression que « IMAP est lent ».

6) Ne touchez aux réglages qu’après (et changez une chose à la fois)

Vous voulez une chaîne causale propre : changement → métrique s’améliore → aucun nouveau mode de défaillance.

Idée paraphrasée (attribuée) : Werner Vogels (CTO d’Amazon) a longtemps promu l’idée de concevoir en prévoyant l’échec et de tout mesurer — parce que la réalité se fiche de vos hypothèses.

Faits et contexte : pourquoi la lenteur IMAP paraît étrange

IMAP semble « lent » d’une manière que les esprits formés au HTTP n’attendent pas. Quelques faits concrets vous aident à raisonner au lieu de deviner.

IMAP est bavard par conception. Beaucoup de clients effectuent de petites commandes (LIST, STATUS, SELECT, FETCH headers) plutôt qu’une grosse requête.
La stratégie d’index de Dovecot est une caractéristique de performance, pas un gadget. Sans index exploitables, Dovecot doit toucher les fichiers de boîte plus souvent, et la latence de stockage devient visible pour l’utilisateur.
Maildir est devenu populaire parce qu’il était simple et évitait certains problèmes de verrouillage. Mais « un fichier par message » peut vous punir sur un stockage à haute latence ou avec un grand nombre d’entrées dans un répertoire.
mbox est plus vieux que votre bip. C’est simple conceptuellement mais peut être pénible avec des gros fichiers et du locking ; les déploiements modernes le choisissent rarement à grande échelle.
Les clients mobiles ont changé la donne. Ils se reconnectent souvent, créant des rafales de sessions courtes qui amplifient les coûts d’auth et de TLS.
IMAP IDLE a réduit le polling mais augmenté les connexions persistantes. Cela déplace la pression des « nombreuses connexions » vers « nombreuses sessions simultanées », ce qui sollicite les limites de workers et la mémoire.
Les métadonnées du système de fichiers sont souvent le goulot d’étranglement. Le mail, c’est beaucoup de petits fichiers, de stat, de rename et d’fsync ; la latence des opérations de métadonnées peut dominer.
Les fichiers d’index peuvent être plus sûrs que vous ne le pensez. Le design des index de Dovecot vise la récupérabilité ; le coût est que la récupération (rebuild) est chère à grande échelle.
Le chiffrement et la conformité ont modifié les schémas de stockage. De plus en plus de serveurs utilisent des filesystems chiffrés ou des backends de stockage chiffrés, ce qui peut introduire des pics de latence subtils.

Une des raisons pour lesquelles ce sujet est si agaçant : vous pouvez avoir peu de CPU, beaucoup de RAM et pourtant offrir une terrible expérience IMAP. C’est la latence du stockage et le coût par opération qui rient de vos tableaux de bord.

Commencez par une base : mesurer où le temps va

Nous avons besoin d’une base. Pas « les utilisateurs disent que c’est lent », mais « FETCH est à 800 ms p95 et 2,2 s p99, corrélé avec 30 ms d’attente sur le volume mail ». Une fois que vous avez ça, vous pouvez tuner avec un but.

Décidez ce que vous optimisez

Latence de connexion (auth + TLS + spawn de processus)
Latence d’ouverture de dossier (lectures d’index + métadonnées de boîte)
Latence liste de messages (index + cache)
Latence fetch de message (débit de stockage + cache)
Latence de recherche (FTS vs balayage brut)

Puis choisissez deux méthodes de mesure : une centrée utilisateur (mesures IMAP) et une centrée système (latence I/O, CPU steal, profondeur de file). Si vous ne regardez qu’une seule, vous vous tromperez.

Blague #1 : Si votre monitoring dit « tout est vert » alors que les utilisateurs sont furieux, félicitations — vous avez construit un très bon menteur fiable.

Les 7 réglages qui comptent vraiment

Ce sont les boutons qui décident régulièrement si Dovecot est réactif ou lent. Vous remarquerez un thème : la plupart des lenteurs IMAP sont des comportements de stockage, d’index ou d’auth — exprimés via Dovecot.

1) `mail_location` et votre choix de format de boîte

mail_location n’est pas qu’un chemin. C’est un pari sur les schémas d’E/S.

Maildir : beaucoup de petits fichiers, métadonnées lourdes, problèmes d’évolutivité des répertoires, mais portée de corruption au niveau du fichier prévisible.
mdbox/sdbox : formats natifs Dovecot, optimisés pour les performances et le comportement de stockage, généralement moins d’objets filesystem, souvent meilleurs sur un stockage à latence élevée ou distant.

Quand IMAP est « lent », Maildir se traduit souvent par « STAT() lent, open() lent, readdir() lent, fsync() lent » sur un volume qui n’a jamais été dimensionné pour des IOPS de métadonnées. mdbox/sdbox aide souvent, mais migrer de format n’est pas un changement anodin du mardi.

Opinion : Si vous opérez à une échelle significative et que votre stockage n’est pas extrêmement rapide en métadonnées, envisagez fortement les formats natifs de Dovecot. Si vous êtes petit, Maildir convient. Si vous êtes moyen et en croissance, Maildir finira par vous envoyer une facture.

Modes de défaillance influencés par ce réglage

Nombre massif d’entrées dans des répertoires provoquant latence readdir/list.
Outils de sauvegarde/restauration qui s’étouffent sur « des millions de petits fichiers ».
Contrôles de filesystem ou opérations de snapshot lents.

2) Index : emplacement et comportement (le vrai levier de performance)

Les index sont là où Dovecot justifie son existence. Un mauvais emplacement d’index transforme votre SSD rapide en SSD triste.

Les réglages qui ont tendance à compter en production :

mail_index_path (ou utiliser le défaut par boîte) : où résident les fichiers d’index.
mail_index_log2_max_age : combien de temps garder les logs de transaction avant compactage.
mail_fsync / maildir_very_dirty_syncs (selon le format) : impacte durabilité vs latence.

Conseil pratique : placez les index sur le stockage le plus rapide et le moins latent que vous avez. Si vous ne pouvez pas, évitez au moins de les placer sur le tier le plus lent. L’I/O d’index est souvent petite mais sensible à la latence. Mettre l’I/O d’index sur un stockage à haute latence, c’est comme exécuter le WAL de votre base de données sur une clé USB.

Pourquoi le tuning d’index fonctionne (et pourquoi il peut nuire)

Les index réduisent les lectures de fichiers de boîte et accélèrent les opérations courantes. Mais le churn d’index peut devenir une charge à part entière. Si vous forcez des rebuilds (corruption, problèmes de permissions, bizarreries d’inodes, cas limites NFS), « IMAP lent » devient « IMAP reconstruit constamment sa mémoire ».

3) Limites de processus : services Dovecot, concurrence et files d’attente

Dovecot est un ensemble de services : imap, imap-login, auth, etc. Les contrôles de concurrence ne sont pas seulement « plus c’est plus rapide ». Plus peut signifier plus d’E/S parallèle et plus de contentions de verrou.

Les réglages les plus importants en production :

service imap { process_limit, service_count }
service imap-login { process_limit }
default_process_limit (défaut global)
service anvil {} (suivi des connexions ; impacte indirectement le comportement sous charge)

Opinion : N’augmentez pas les limites de processus aveuglément parce que « nous avons 32 cœurs ». La charge IMAP est généralement limitée par l’I/O. Si vous augmentez la concurrence sur un stockage déjà lié à la latence, vous pouvez augmenter la latence des queues et empirer l’expérience utilisateur.

Modes de défaillance

Trop bas : files d’attente de login, clients « bloqués », pics périodiques.
Trop haut : amplification d’I/O, contentions de locks, contention des index, pression mémoire.

4) Cache d’auth : arrêtez de payer LDAP/SQL à chaque connexion

Dovecot peut authentifier via PAM, LDAP, SQL ou d’autres backends. Beaucoup d’organisations construisent une belle pile d’identité centralisée… puis oublient que les clients mobiles se reconnectent constamment et vont volontiers DDoS votre annuaire avec des logins légitimes.

Réglages importants :

auth_cache_size
auth_cache_ttl
auth_cache_negative_ttl

Ce que vous voulez : mettre en cache les authentifications réussies assez longtemps pour lisser les rafales de reconnexions, mais pas si longtemps que vous ignorez les changements de mot de passe pendant des heures. Mettre en cache les négatifs brièvement pour éviter l’amplification brute-force sans verrouiller les utilisateurs légitimes trop longtemps.

Avertissement : le cache d’auth ne corrige pas un LDAP/SQL lent ; il le masque la plupart du temps. Corrigez quand même le backend. Mais le cache fait la différence entre « un mardi lent » et « un incident ».

5) Réglages SSL/TLS qui se manifestent comme « IMAP lent »

Les utilisateurs disent « le mail est lent ». Vos graphiques montrent « CPU ok ». Pendant ce temps, chaque connexion effectue une crypto coûteuse, du travail de chaîne de certificats, et parfois des recherches DNS pour OCSP ou CRL au mauvais endroit.

Réglages qui comptent :

ssl (required/yes/no)
ssl_min_protocol
ssl_cipher_list (faites attention)
ssl_prefer_server_ciphers
ssl_options (le comportement des tickets de session peut importer selon la version)

Opinion : N’« optimisez » pas TLS en forçant des listes de chiffrements exotiques sauf si vous savez ce que vous faites. Les valeurs par défaut modernes sont généralement sensées. Le gain de performance le plus courant est de réduire la fréquence des reconnexions (comportement client) et de s’assurer d’avoir assez de capacité imap-login et de marge CPU pour les rafales de handshake.

6) Recherche plein texte : faites-le bien, ou n’en faites pas semblant

La recherche est l’endroit où la performance IMAP meurt. Sans FTS, les clients qui font des SEARCH côté serveur peuvent déclencher des balayages brutaux des corps de message. Avec un backend FTS mal configuré, vous avez la même douleur plus le surcoût d’indexation.

Les réglages importants dépendent du backend choisi, mais la partie importante est la décision :

Activez un vrai backend FTS et assurez-vous qu’il est sain et dimensionné, ou
Acceptez que SEARCH soit coûteux et gérez les attentes et le comportement des clients.

Opinion : Si vous servez des knowledge workers qui vivent dans la recherche, investissez correctement dans le FTS. Si vous servez surtout des workflows de tri d’inbox, n’introduisez pas un sous-système de recherche fragile juste pour pouvoir le dire.

7) Métriques/journalisation : si vous ne pouvez pas mesurer, vous ne pouvez pas corriger

Dovecot peut vous dire ce qu’il fait. L’astuce est d’activer la bonne visibilité sans mettre vos disques en feu avec des logs.

Réglages et outils utiles en pratique :

log_path, info_log_path, debug_log_path (à utiliser avec parcimonie)
auth_verbose (attention à la confidentialité)
mail_debug (temporaire)
stats / intégration d’exporter métriques (varie selon le déploiement)

Opinion : Ne laissez pas de debug permanent en production à moins d’aimer payer pour des disques et d’expliquer pourquoi la timeline d’incident manque parce que logrotate a pris du retard.

Trois mini-récits d’entreprise (anonymisés, plausibles, douloureusement familiers)

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne a déplacé le stockage des mails d’un SSD local vers un filesystem attaché au réseau. En interne, on l’avait vendu comme « plus rapide et plus résilient », parce que l’array de stockage avait des chiffres de throughput impressionnants sur une diapositive. Personne n’a demandé la latence des métadonnées ni la charge de petits fichiers.

En quelques jours, IMAP est devenu collant : ouvrir des dossiers prenait des secondes, et les clients mobiles expiraient et se reconnectaient, ce qui faisait monter le trafic d’auth, et empirait tout. Les graphiques étaient étranges : CPU faible sur les hosts mail, usage réseau modéré, mais I/O wait élevé par rafales.

La première idée de l’équipe fut d’augmenter les limites de processus Dovecot. Logique en surface — plus de workers, plus de progrès. En réalité, cela a augmenté les opérations metadata parallèles sur un stockage déjà lié à la latence, aggravant la latence de queue. Les utilisateurs rapportaient « parfois ça va, parfois ça fige », la marque d’un phénomène de mise en file plus gigue.

La correction n’a rien de magique. Ils ont relocalisé les index Dovecot sur SSD local tout en laissant les corps de messages sur le stockage réseau, réduit la concurrence pour arrêter les bousculades auto-induites, et ajouté du cache d’auth pour amortir les tempêtes de reconnexions. La leçon : les benchmarks de throughput ne prédisent pas la performance IMAP ; la latence et le comportement des métadonnées le font.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation a vu des SEARCH lents et a décidé de « l’accélérer » en activant rapidement un backend FTS, avec des tests minimaux. Ils ont activé l’indexation pour tout, y compris de grosses boîtes partagées et des comptes de journalisation automatisée à haut volume.

Pendant la première heure, ça avait l’air réussi. Les recherches revenaient vite pour un sous-ensemble d’utilisateurs — parce que l’index était chaud pour les comptes testés. Puis l’indexeur a commencé à rattraper le retard sur l’ensemble du parc. L’I/O disque est monté, le CPU a grimpé, et les latences IMAP ont commencé à dériver à la hausse.

Le vrai problème n’était pas que FTS soit mauvais. C’était qu’ils ont traité l’indexation comme un addon gratuit. Ils n’avaient pas budgété les IOPS, n’avaient pas planifié l’indexation initiale, et n’avaient pas isolé le stockage d’index du stockage des boîtes. Ils n’avaient pas non plus plafonné la concurrence d’indexation, donc l’indexeur a rivalisé avec le trafic utilisateur.

Ils ont fini par limiter l’indexation, isoler les fichiers d’index sur un tier plus rapide, et exclure les comptes pathologiques du FTS. La recherche s’est améliorée et le système a cessé de fondre. Mais il a fallu un incident pour comprendre que « activer le FTS » est une migration de charge, pas une case à cocher.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise réglementée exécutait Dovecot sur du matériel modeste mais avait l’habitude disciplinée suivante : chaque trimestre, ils testaienent la restauration d’une boîte et exécutaient des vérifications d’intégrité sur un échantillon de comptes. Rien de héroïque, juste du travail programmé et un runbook.

Une semaine, les utilisateurs se sont plaints d’ouvertures de dossiers lentes et de « messages manquants » dans quelques boîtes. L’astreinte a trouvé des messages de rebuild d’index élevés dans les logs. Parce qu’ils disposaient de timings de base et d’un comportement connu bon, ils ont rapidement suspecté une corruption d’index ou un problème de filesystem plutôt que « lenteur aléatoire ».

Ils ont utilisé doveadm pour forcer les reconstructions d’index sur les boîtes affectées pendant une fenêtre contrôlée, vérifié la santé du filesystem et contrôlé la latence du stockage sous-jacent. L’incident est resté limité à un petit nombre d’utilisateurs, et les performances sont redevenues normales après les rebuilds.

Rien de glamour. Pas de nouvelle techno. Mais la discipline ennuyeuse — tester les restaurations, garder des runbooks et échantillonner la santé des boîtes — leur a permis de reconnaître le mode de défaillance tôt et de ne pas s’agiter en changeant des réglages non liés.

Erreurs courantes (symptôme → cause racine → correction)

Voici la partie où on arrête de prétendre que chaque environnement est unique. Ces schémas se répètent entre entreprises parce que les humains se répètent eux-mêmes.

1) Symptôme : la connexion prend 2–10 secondes, puis tout va bien

Cause racine : backend d’auth lent (LDAP/SQL), cache d’auth manquant, ou rafales de handshake TLS qui saturent imap-login.
Correction : activez auth_cache_size/auth_cache_ttl, vérifiez la latence du backend, n’augmentez service imap-login process_limit que si le CPU peut le supporter.

2) Symptôme : ouvrir des dossiers est lent, mais fetch du corps est OK

Cause racine : latence I/O d’index ou rebuilds d’index ; fréquent aussi avec stockage métadonnées à haute latence.
Correction : déplacez les index vers un stockage plus rapide via mail_index_path, investiguez les causes de corruption d’index, vérifiez les options de montage du filesystem et la latence.

3) Symptôme : LIST/STATUS est lent sur de nombreux dossiers

Cause racine : trop de boîtes + lookups de status coûteux, client demandant STATUS pour chaque dossier, ou latence de namespace/mount distant.
Correction : assurez-vous que les index sont sains, envisagez des changements de politique client, évitez le stockage distant à latence élevée pour des workloads Maildir lourds.

4) Symptôme : SEARCH fait « geler » le serveur

Cause racine : pas de FTS et balayages brutaux ; ou indexation FTS en concurrence avec IMAP pour l’I/O.
Correction : implémentez le FTS correctement (stockage isolé, indexation limitée) ou limitez le comportement de recherche et gérez les attentes.

5) Symptôme : pics aléatoires, p99 catastrophique, les moyennes semblent correctes

Cause racine : jitter de stockage, mise en file, concurrence excessive, compaction/rebuild périodique d’index.
Correction : mesurez I/O await et profondeur de file, dimensionnez correctement les limites de processus, et traitez d’abord le niveau stockage.

6) Symptôme : c’est plus lent après avoir « optimisé » en augmentant la concurrence

Cause racine : vous avez augmenté l’I/O parallèle au-delà de ce que le stockage peut servir avec une faible latence.
Correction : réduisez le nombre de workers ; optimisez pour la latence, pas le débit maximal ; isolez les index sur des médias plus rapides.

Blague #2 : Ajouter plus de processus IMAP à un disque lent, c’est comme ouvrir plus de caisses quand vous n’avez qu’un seul caissier.

Tâches pratiques : commandes, signification des sorties et la décision que vous prenez

Vous vouliez des tâches concrètes. Voici plus d’une douzaine, chacune avec une commande, une sortie d’exemple, ce que ça signifie et ce que vous faites ensuite. Lancez-les dans l’ordre quand vous êtes en astreinte et fatigué.

Task 1: Confirm Dovecot version and enabled components

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

Ce que cela signifie : Vous êtes sur la branche 2.3.x. Certains réglages et valeurs par défaut diffèrent selon la version.

Décision : N’appliquez pas aveuglément des conseils écrits pour 1.x/2.0. Gardez vos réglages dans les capacités et valeurs par défaut de votre version.

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

Ce que cela signifie : Vous êtes en Maildir, limites de processus élevées, et cache d’auth désactivé.

Décision : Notez ceci comme « probabilité de pression sur les métadonnées de stockage » plus « backend d’auth possiblement chaud ». Vous savez maintenant quels boutons sont réellement actifs.

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

Ce que cela signifie : Les sessions actives sont visibles. Si cette liste est énorme et stable, vous avez beaucoup de connexions concurrentes (IDLE, mobile).

Décision : Si les connexions sont élevées, vérifiez les limites de processus et la mémoire. Si les utilisateurs se plaignent de logins pendant les pics, imap-login peut être saturé.

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

Ce que cela signifie : La charge est élevée. La charge seule ne prouve pas la saturation CPU ; elle inclut les tâches en attente d’E/S.

Décision : Vérifiez immédiatement I/O wait et la latence disque. Charge élevée + CPU faible indique souvent un problème d’E/S.

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

Ce que cela signifie : md0 est presque saturé (%util ~95) avec un await élevé (~36 ms). C’est une latence visible par l’utilisateur pour des workloads riches en stat/index.

Décision : Traitez la latence stockage comme la priorité n°1. Réduire la concurrence peut améliorer la latence des queues immédiatement ; la correction à plus long terme est la conception du stockage.

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

Ce que cela signifie : ext4 avec options assez par défaut. C’est correct, mais pas forcément optimal pour votre pattern mail.

Décision : Ne changez pas au hasard les options de montage en production pour poursuivre des performances sans comprendre l’impact sur la durabilité. Mesurez le coût d’fsync et le churn d’index 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

Ce que cela signifie : Les workers IMAP sont actifs ; login et auth montrent aussi du CPU. Si vous voyez beaucoup de processus court-vie, vous gérez peut-être des rafales de reconnexions.

Décision : Si login/auth est élevé pendant les plaintes utilisateurs, priorisez le cache d’auth et l’investigation du backend.

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

Ce que cela signifie : Vous avez deux serveurs DNS configurés. Si l’un est lent ou mort, certaines résolutions peuvent bloquer.

Décision : Si les logins lents se corrèlent à des timeouts DNS dans syslog, corrigez le DNS d’abord. Ne tunez pas Dovecot autour d’une plomberie cassée.

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

Ce que cela signifie : Des rebuilds d’index ont lieu sous charge utilisateur, et des locks FTS expirent. Cela se manifestera par de la lenteur et des blocages « aléatoires ».

Décision : Investiguer pourquoi les index se corrompent ou se verrouillent. Envisagez de relocaliser les index, vérifier les permissions et évaluer la latence/les sémantiques de locking du stockage.

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

Ce que cela signifie : ~186k fichiers pour un utilisateur (incluant indexes, tmp, cur/new). C’est beaucoup de métadonnées.

Décision : Si beaucoup d’utilisateurs ressemblent à cela et que la latence stockage n’est pas négligeable, Maildir sera un problème récurrent. Envisagez mdbox/sdbox ou relocalisation d’index et maintenance agressive.

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

Ce que cela signifie : L’ouverture d’INBOX a pris 412 ms côté serveur. C’est déjà dans la zone où l’utilisateur remarque.

Décision : Concentrez-vous sur le coût d’ouverture d’index et la latence de stockage. Si les ouvertures sont lentes, FETCH le sera aussi, avec des symptômes différents.

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

Ce que cela signifie : Le cache d’index est de 50 Mo pour cette boîte. Ce n’est pas automatiquement mauvais, mais c’est beaucoup d’E/S si c’est constamment réécrit.

Décision : Si les index sont sur un stockage lent, déplacez-les. Si des corruptions/rebuilds surviennent, investiguez la cause sous-jacente avant de changer la taille du cache.

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

Ce que cela signifie : ~482 ms pour un test d’auth. C’est trop lent si les clients se reconnectent fréquemment.

Décision : Activez le cache d’auth et corrigez la performance du backend (indexes SQL, tuning LDAP, chemin réseau). Si le backend est distant, la latence apparaîtra comme « IMAP lent ».

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

Ce que cela signifie : Le soft limit 1024 peut être trop bas pour un serveur IMAP occupé avec de nombreuses connexions concurrentes et des fichiers Maildir.

Décision : Augmentez les limites via des overrides systemd ou la configuration d’initialisation appropriée. Si vous atteignez les limites, vous aurez des erreurs et des retries qui ressemblent à de la lenteur.

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

Ce que cela signifie : Vous swappez. Ça transforme « parfois lent » en « tout est lent », surtout sous des rafales de connexions.

Décision : Réduisez la concurrence, ajoutez de la RAM, corrigez les fuites mémoire, et arrêtez le swap. Si vous devez swapper, vous êtes déjà en mode survie.

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))

Ce que cela signifie : Beaucoup de connexions établies se trouvent brièvement sur imap-login pendant le handshake/auth avant d’être basculées.

Décision : Si les processus imap-login sont saturés aux heures de pointe, ajustez process_limit pour imap-login et assurez-vous d’avoir du CPU disponible. Réduisez aussi les schémas de reconnexion si possible (réglages client, comportement du load balancer).

Check-lists / plan pas à pas

Checklist A : « IMAP est lent maintenant » (30 minutes)

Identifiez ce qui est lent : login vs LIST vs SELECT vs FETCH vs SEARCH (demandez à un utilisateur affecté le comportement exact).
Exécutez doveconf -n pour capturer les réglages effectifs (enregistrez la sortie dans les notes d’incident).
Vérifiez la latence stockage avec iostat -x. Si await est élevé, arrêtez de tuner Dovecot et traitez le stockage comme le goulot.
Vérifiez les logs Dovecot pour messages de rebuild/corruption d’index.
Vérifiez la latence d’auth avec doveadm auth test et activez le cache d’auth si nécessaire.
Vérifiez les comptes de connexion et la saturation imap-login (doveadm who, ss, ps).
Si swap : réduisez la concurrence, stoppez l’hémorragie, puis planifiez la montée en capacité.

Checklist B : Tuning sans créer un nouvel incident (1–2 jours)

Choisissez une métrique cible : p95 SELECT, p95 login, ou temps de SEARCH pour une boîte représentative.
Déplacez les index vers un stockage rapide si actuellement co-localisés avec un stockage boite lent. Validez permissions et stratégie de sauvegarde.
Implémentez auth_cache_size et des TTLs sensés ; validez le comportement des changements de mot de passe avec les parties prenantes.
Dimensionnez correctement les limites de processus : commencez conservateur, puis augmentez jusqu’à ce que la latence cesse de s’améliorer.
Décidez de la stratégie FTS : implémenter correctement ou pas. Évitez les états à moitié configurés.
Vérifiez les résultats avec les mêmes commandes et une boîte de test cohérente.

Checklist C : Correctifs structurels (1–6 semaines)

Évaluez le format des boîtes : si Maildir tue vos métadonnées, planifiez une migration vers mdbox/sdbox avec plan de rollback.
Corrigez le stockage : priorisez la latence et les IOPS métadonnées. Les chiffres de throughput ne suffisent pas.
Mettez en place la gestion de capacité : limites de descripteurs de fichiers, taille mémoire, et concurrence prédictible.
Établissez des fenêtres de maintenance pour rebuilds d’index / reindexation FTS afin d’éviter la douleur en journée.

FAQ

1) Pourquoi IMAP est lent alors que le CPU est bas ?

Parce qu’IMAP est souvent lié à la latence du stockage. CPU bas avec iowait élevé et await disque élevé est classique. Dovecot passe du temps à attendre les métadonnées du filesystem et l’I/O d’index.

2) Dois-je simplement augmenter `service imap { process_limit }` ?

Seulement si vous avez prouvé que vous êtes lié au CPU ou que Dovecot est en file d’attente. Si la latence stockage est le goulot, plus de workers peut empirer la latence tail en augmentant la concurrence d’I/O.

3) Maildir est-il intrinsèquement lent ?

Non. Maildir peut être rapide sur un stockage local à faible latence avec de bonnes performances métadonnées. Il devient lent quand vous augmentez le nombre de fichiers, utilisez un stockage à haute latence, ou créez de grandes hiérarchies de dossiers qui amplifient les opérations métadonnées.

4) Quelle est la meilleure amélioration unique pour la latence d’ouverture de dossier ?

Des index sains sur un stockage rapide. Cela signifie souvent relocaliser les fichiers d’index (via mail_index_path) et arrêter la cause sous-jacente des rebuilds.

5) Ai-je besoin de FTS ?

Si vos utilisateurs comptent sur des recherches côté serveur dans les corps et pièces jointes, oui — implémentez-le correctement. Si les recherches sont rares, le FTS peut devenir un élément fragile et générer de l’I/O pour peu de bénéfice.

6) Pourquoi les clients mobiles empirent-ils tout ?

Ils se reconnectent fréquemment, ce qui amplifie les coûts de login/auth/TLS et augmente la churn de concurrence. Sans cache d’auth et sans capacité imap-login adéquate, vous obtenez des tempêtes périodiques « le mail est lent ».

7) Comment savoir si les index se corrompent ?

Les logs mentionneront la reconstruction des fichiers d’index ou des fichiers cache/index corrompus. Les utilisateurs peuvent voir des ouvertures de dossier lentes et des listes de messages incohérentes. Confirmez via revue de logs et opérations ciblées doveadm.

8) Les réglages TLS peuvent-ils vraiment causer de la lenteur IMAP ?

Oui, surtout si vous avez des rafales de connexion ou des workers imap-login sous-dimensionnés. Le coût du handshake TLS devient visible quand il est multiplié par beaucoup de reconnexions.

9) Que faire si SEARCH est lent mais le reste est OK ?

C’est généralement « pas de FTS » ou « FTS pas à jour ». Décidez d’investir dans l’indexation de recherche ou acceptez que SEARCH reste coûteux par conception.

Prochaines étapes réalisables cette semaine

Exécutez le plan d’intervention rapide et capturez des preuves : doveconf -n, iostat -x, extraits de logs pertinents et un test doveadm fetch chronométré.
Si la latence stockage est élevée, traitez-la comme la cause racine. Réduisez la concurrence pour baisser la contention et commencez un plan pour déplacer les index vers des médias plus rapides.
Activez le cache d’auth si vous avez un backend d’auth distant et une population mobile significative. Ajustez les TTL pour ne pas surprendre les équipes sécurité.
Dimensionnez correctement les limites de processus avec des données : augmentez jusqu’à ce que la latence cesse de s’améliorer, puis arrêtez. Chercher à « maximiser » les workers maximise les incidents.
Prenez une décision claire sur la recherche : implémentez le FTS correctement (ressources isolées, indexation contrôlée), ou acceptez SEARCH plus lent et évitez d’instabiliser le système.
Ajoutez des garde-fous : limites de descripteurs, éviter le swap, et métriques légères qui indiquent si vous êtes lié à l’auth, aux index ou au stockage.

Si vous ne faites qu’une chose : mesurez la latence I/O et la santé des index avant de changer des réglages. La plupart des « optimisations » Dovecot sont en réalité de l’ingénierie stockage et de la discipline opérationnelle sous un chapeau mail.