Dovecot: IMAP lento — Los 7 ajustes que realmente importan

febrero 20, 2026 • febrero 20, 2026 • Lectura: 27 min • Views: 0

¿Te fue útil?

El IMAP lento es un tipo especial de dolor: los usuarios culpan “al correo”, los directivos culpan “al servidor” y tú terminas mirando iostat a las 2 a.m. preguntándote por qué abrir un mensaje de 12 KB tarda tres segundos. Dovecot normalmente no es el villano. Es el mensajero que trae la verdad sobre tu almacenamiento, índices, la tubería de autenticación y un puñado de ajustes que deciden si Dovecot es un bisturí o un cuchillo para untar.

Esta es la guía de campo para arreglarlo sin tuning de culto. Siete ajustes importan de forma desproporcionada. El resto son principalmente adorno. Primero diagnosticaremos, luego afinaremos y finalmente verificaremos con comandos que puedes ejecutar ahora mismo.

Guía de diagnóstico rápido

Si IMAP está lento, no empiezas cambiando ajustes aleatorios de Dovecot. Empiezas demostrando de dónde proviene la latencia: autenticación, TLS, índices de Dovecot, almacenamiento del buzón o la red. Aquí tienes el orden de operaciones más rápido que he encontrado y que no te hace perder el día.

1) Confirma qué significa “lento” (login, LIST, SELECT, FETCH, SEARCH)

Login lento normalmente significa latencia en el backend de auth, DNS o comportamiento del handshake TLS.
Listado de carpetas lento apunta a descubrimiento de namespaces, problemas de índices o latencia en metadata de almacenamiento.
Abrir/SELECT lento a menudo significa reconstrucciones de índice, comportamiento de fsync o alta latencia de I/O.
FETCH del cuerpo lento casi siempre es rendimiento/latencia de almacenamiento o patología/ formato del buzón.
SEARCH lento es o la ausencia de FTS (así que escanea) o un FTS malo (así que degrada con thrashing).

2) Comprueba saturación global de recursos

Antes de culpar a Dovecot, verifica si la máquina está ahogada. Si el promedio de I/O wait es alto, Dovecot parecerá “lento” porque espera su turno de forma educada.

3) Busca síntomas de churn o corrupción de índices

Las reconstrucciones de índices pueden convertir un sistema sano en un desastre pegajoso. Verás CPU, disco y muchos archivos de índice reescribiéndose.

4) Valida la ruta de autenticación y caches

Si cada conexión IMAP provoca una consulta LDAP/SQL lenta, experimentarás “todo lento”, especialmente con conexiones móviles de corta duración.

5) Valida concurrencia y límites

Muy pocos workers causan colas. Demasiados causan una estampida sobre el almacenamiento. Ambos se sienten como “IMAP lento”.

6) Solo entonces toca ajustes (cambia una cosa a la vez)

Quieres una cadena causal limpia: cambio → métrica mejora → no aparece un nuevo modo de fallo.

Idea parafraseada (atribuida): Werner Vogels (CTO de Amazon) ha defendido durante mucho tiempo la idea de diseñar para el fallo y medir todo, porque la realidad no se preocupa por tus suposiciones.

Hechos y contexto: por qué la lentitud IMAP se ve extraña

IMAP se siente “lento” de maneras que las mentes entrenadas en HTTP no esperan. Algunos hechos concretos te ayudan a razonar en lugar de adivinar.

IMAP es conversacional por diseño. Muchos clientes hacen muchos comandos pequeños (LIST, STATUS, SELECT, FETCH headers) en lugar de una sola petición grande.
La estrategia de índices de Dovecot es una característica de rendimiento, no un lujo. Sin índices utilizables, Dovecot tiene que tocar los archivos de buzón más a menudo y la latencia de almacenamiento se vuelve visible para el usuario.
Maildir se popularizó por simplicidad y evitar problemas de bloqueo. Pero “un archivo por mensaje” puede castigarte en almacenamiento de alta latencia o con conteos enormes de directorios.
mbox es más antiguo que tu buscapersonas. Es conceptualmente simple pero puede doler con archivos grandes y locking; los despliegues modernos raramente lo eligen para IMAP a gran escala.
Los clientes móviles cambiaron las reglas. Se reconectan con frecuencia, creando ráfagas de sesiones cortas que amplifican los costes de auth y TLS.
IMAP IDLE redujo el polling pero aumentó conexiones de larga duración. Eso desplaza la presión de “muchas conexiones” a “muchas sesiones concurrentes”, lo que estresa límites de workers y memoria.
La metadata del sistema de ficheros suele ser el cuello de botella. El correo son muchos archivos pequeños, stat, rename y fsync; la latencia en operaciones de metadata puede dominar.
Los archivos de índice pueden ser más seguros de lo que piensas. El diseño de índices de Dovecot está pensado para ser recuperable; el coste es que la recuperación (reconstrucción) es cara cuando ocurre a gran escala.
Cifrado y cumplimiento cambiaron los patrones de almacenamiento. Más servidores usan sistemas de ficheros o backends de almacenamiento cifrados, lo que puede introducir picos de latencia sutiles.

Una de las razones por las que este tema es tan irritante: puedes tener CPU baja, RAM suficiente y aun así ofrecer una experiencia IMAP terrible. Eso es la latencia de almacenamiento y la sobrecarga por operación riéndose de tus dashboards.

Línea base primero: medir dónde va el tiempo

Necesitamos una línea base. No “los usuarios dicen que está lento”, sino “FETCH es 800 ms p95 y 2.2 s p99, correlacionado con 30 ms de await en el volumen de correo”. Una vez tengas eso, puedes ajustar con intención.

Decide qué estás optimizando

Latencia de login (auth + TLS + creación de proceso)
Latencia de apertura de carpeta (lecturas de índice + metadata de buzón)
Latencia del listado de mensajes (índice + caché)
Latencia de fetch de mensaje (throughput de almacenamiento + caching)
Latencia de búsqueda (FTS vs fuerza bruta)

Luego elige dos métodos de medición: uno centrado en el usuario (tiempos IMAP) y otro centrado en el sistema (latencia I/O, CPU steal, profundidad de cola). Si solo miras uno, te engañarás a ti mismo.

Broma #1: Si tu monitorización dice “todo verde” mientras los usuarios están furiosos, felicitaciones: has construido a un mentiroso muy confiable.

Los 7 ajustes que realmente importan

Estos son los mandos que regularmente deciden si Dovecot se siente ágil o lento. Notarás un tema: la mayoría de la “lentitud IMAP” es comportamiento de almacenamiento, comportamiento de índices o comportamiento de autenticación—expresado a través de Dovecot.

1) `mail_location` y la elección del formato de buzón

mail_location no es solo una ruta. Es una apuesta sobre patrones de I/O.

Maildir: muchos archivos pequeños, metadata intensiva, problemas de escalado de directorios, pero alcance de corrupción predecible a nivel de archivo.
mdbox/sdbox: formatos nativos de Dovecot, optimizados para rendimiento y comportamiento de almacenamiento, generalmente menos objetos en el sistema de ficheros y a menudo mejores en almacenamiento remoto o de alta latencia.

Cuando IMAP está “lento”, Maildir a menudo lo traduce en “STAT() lento, open() lento, readdir lento, fsync lento” en un volumen que nunca fue dimensionado para IOPS de metadata. mdbox/sdbox suele ayudar, pero migrar formatos no es un cambio de martes casual.

Opinión: Si operas a escala significativa y tu almacenamiento no es extremadamente rápido en metadata, considera en serio los formatos nativos de Dovecot. Si eres pequeño, Maildir está bien. Si eres mediano y creces, Maildir eventualmente te pasará una factura.

Modos de fallo que influye este ajuste

Conteos masivos de directorios que causan latencia en readdir/list.
Herramientas de backup/restore atrancándose con “millones de archivos diminutos”.
Checks del sistema de ficheros o operaciones de snapshot lentas.

2) Índices: ubicación y comportamiento (la palanca real de rendimiento)

Los índices son donde Dovecot justifica su existencia. Colocar mal los índices convierte tu SSD en un SSD triste.

Los ajustes que suelen importar en la vida real:

mail_index_path (o usar el valor por defecto por buzón): dónde viven los archivos de índice.
mail_index_log2_max_age: cuánto tiempo mantener logs de transacción antes de compactar.
mail_fsync / maildir_very_dirty_syncs (según el formato): impacto en durabilidad vs latencia.

Consejo práctico: coloca los índices en el almacenamiento más rápido y de baja latencia que tengas. Si no puedes, al menos evita colocarlos en la capa más lenta. I/O de índices suele ser pequeño pero sensible a latencia. Poner I/O de índices en almacenamiento de alta latencia es como correr el WAL de tu base de datos en una memoria USB.

Por qué afinar índices funciona (y por qué puede empeorar)

Los índices reducen lecturas de archivos de buzón y aceleran operaciones comunes. Pero el churn de índices puede convertirse en su propia carga de trabajo. Si fuerzas reconstrucciones constantemente (corrupción, problemas de permisos, rarezas de inodos, casos límite de NFS), “IMAP lento” se convierte en “IMAP está reconstruyéndose constantemente”.

3) Límites de proceso: servicios de Dovecot, concurrencia y colas

Dovecot es un conjunto de servicios: imap, imap-login, auth, etc. Los controles de concurrencia no son solo “más es más rápido”. Más puede significar más I/O paralelo y más contención por locks.

Ajustes que más importan en producción:

service imap { process_limit, service_count }
service imap-login { process_limit }
default_process_limit (valor por defecto global)
service anvil {} (seguimiento de conexiones; impacta indirectamente bajo carga)

Opinión: No aumentes límites de proceso a ciegas porque “tenemos 32 cores”. La carga IMAP suele estar limitada por I/O. Si incrementas concurrencia en una capa de almacenamiento ya limitada por latencia, puedes aumentar la latencia en la cola y empeorar la experiencia del usuario.

Modos de fallo

Demasiado bajo: colas de login, clientes “colgados”, picos periódicos.
Demasiado alto: amplificación de I/O, contención por locks, contención de índices, presión de memoria.

4) Caché de autenticación: deja de pagar por LDAP/SQL en cada conexión

Dovecot puede autenticarse contra PAM, LDAP, SQL u otros backends. Muchas organizaciones construyen una bonita pila de identidad centralizada… y luego olvidan que los clientes móviles se reconectan constantemente y felizmente DDoSean tu directorio con logins legítimos.

Ajustes que importan:

auth_cache_size
auth_cache_ttl
auth_cache_negative_ttl

Lo que quieres: cachear autenticaciones exitosas el tiempo suficiente para suavizar picos de reconexión, pero no tanto como para ignorar cambios de contraseña durante horas. Cachea negativos brevemente para evitar amplificación de fuerza bruta sin bloquear usuarios legítimos demasiado tiempo.

Aviso: la caché de auth no arregla LDAP/SQL lento; lo oculta la mayor parte del tiempo. Aun así arregla el backend. Pero la caché es la diferencia entre “un martes lento” y “un incidente”.

5) Ajustes SSL/TLS que aparecen como “IMAP lento”

Los usuarios lo llaman “correo lento”. Tus gráficas muestran “CPU bien”. Mientras tanto, cada conexión está haciendo criptografía cara, trabajo con la cadena de certificados y a veces búsquedas DNS para OCSP o comprobaciones CRL en el lugar equivocado.

Ajustes que importan:

ssl (required/yes/no)
ssl_min_protocol
ssl_cipher_list (ten cuidado)
ssl_prefer_server_ciphers
ssl_options (el comportamiento de session tickets puede importar según la versión)

Opinión: No “optimices” TLS forzando listas de cifrado exóticas salvo que sepas lo que haces. Los valores por defecto modernos suelen ser razonables. La ganancia de rendimiento más común es reducir la frecuencia de reconexiones (comportamiento del cliente) y asegurar que tengas suficiente capacidad de imap-login y CPU para ráfagas de handshakes.

6) Búsqueda de texto completo: o lo haces bien, o no finjas tenerla

La búsqueda es donde el rendimiento IMAP va a morir. Sin FTS, los clientes que hacen SEARCH en el servidor pueden desencadenar escaneos por fuerza bruta a través de cuerpos de mensajes. Con un backend FTS mal configurado obtienes el mismo dolor más la sobrecarga de indexación.

Los ajustes que importan dependen del backend elegido, pero lo importante es la decisión:

Habilita un backend FTS real y asegúrate de que esté sano y dimensionado, o
Acepta que SEARCH es costoso y gestiona expectativas y comportamiento del cliente.

Opinión: Si sirves a trabajadores del conocimiento que dependen de la búsqueda, invierte en FTS correctamente. Si sirves principalmente flujos de “triage de bandeja de entrada”, no introduzcas un subsistema de búsqueda frágil solo para decir que lo tienes.

7) Métricas/registro: si no puedes medirlo, no puedes arreglarlo

Dovecot puede decirte qué está haciendo. La clave es activar la visibilidad correcta sin incendiar tus discos con logs.

Ajustes y herramientas que importan en la práctica:

log_path, info_log_path, debug_log_path (usar con moderación)
auth_verbose (cuidado con la privacidad)
mail_debug (temporal)
stats / integración de exportador de métricas (varía por despliegue)

Opinión: No dejes logging en modo debug permanente en producción a menos que disfrutes pagar por discos y explicar por qué la línea temporal del incidente falta porque logrotate se quedó atrás.

Tres micro-historias corporativas (anonimizadas, plausibles, dolorosamente familiares)

Micro-historia 1: El incidente causado por una suposición errónea

Una empresa mediana movió el almacenamiento de correo de SSD local a un sistema de ficheros en red. Se vendió internamente como “más rápido y más resiliente”, porque el array de almacenamiento tenía números de throughput impresionantes en una diapositiva. Nadie preguntó por la latencia de metadata o la carga de archivos pequeños.

En días, IMAP se sintió pegajoso: abrir carpetas tomaba segundos y los clientes móviles hacían time out y se reconectaban, lo que aumentó el tráfico de auth y empeoró todo. Las gráficas parecían extrañas: CPU baja en los hosts de correo, uso de red moderado, pero I/O wait elevado en ráfagas.

La primera reacción del equipo fue aumentar los límites de procesos de Dovecot. Parecía lógico—más workers, más progreso. En realidad aumentó las operaciones metadata paralelas sobre un almacenamiento ya limitado por latencia, empeorando la latencia de cola. Los usuarios reportaron “a veces está bien, a veces se congela”, sello distintivo de colas más jitter.

La solución no fue mágica. Reubicaron los índices de Dovecot a SSD local dejando los cuerpos de mensajes en almacenamiento en red, redujeron la concurrencia para detener estampidas autoinducidas y añadieron caché de auth para amortiguar tormentas de reconexión. La gran lección: los benchmarks de throughput no predicen el rendimiento IMAP; la latencia y el comportamiento de metadata sí.

Micro-historia 2: La optimización que salió mal

Otra organización vio SEARCH lento y decidió “acelerarlo” habilitando rápidamente un backend FTS con pruebas mínimas. Activaron indexación para todo, incluidas bandejas compartidas gigantes y cuentas de journaling automatizado que ingieren gran volumen de mail.

La primera hora pareció un éxito. Las búsquedas devolvían rápido para algunos usuarios—porque el índice estaba caliente para las cuentas que probaron. Luego el indexador empezó a ponerse al día en toda la flota. El I/O de disco subió, la CPU subió y las latencias IMAP comenzaron a aumentar.

El verdadero problema no fue que FTS sea malo. Fue que trataron la indexación como un añadido gratuito. No presupuestaron IOPS, no planificaron la indexación inicial y no aislaron el almacenamiento de índices del almacenamiento de buzones. Tampoco limitaron la concurrencia del indexador, por lo que competía por I/O con el tráfico en vivo.

Terminaron limitando la indexación, aislando archivos de índice en una capa más rápida y excluyendo cuentas patológicas del FTS. La búsqueda mejoró y el sistema dejó de calentarse. Pero fue necesario un incidente para aprender que “activar FTS” es una migración de carga de trabajo, no una casilla para marcar.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Una empresa regulada ejecutaba Dovecot en hardware modesto pero tenía un hábito disciplinado: cada trimestre probaban restaurar un buzón y rutinariamente ejecutaban checks de integridad en una muestra de cuentas. Nada heroico, solo trabajo programado y un runbook.

Una semana, los usuarios empezaron a quejarse de aperturas de carpetas lentas y mensajes “faltantes” en algunos buzones. El on-call encontró mensajes de reconstrucción de índices en los logs. Porque tenían tiempos base y comportamiento conocido, rápidamente sospecharon corrupción de índices o un problema del sistema de ficheros en lugar de “lentitud aleatoria”.

Usaron doveadm para forzar reconstrucciones de índice en los buzones afectados durante una ventana controlada, verificaron la salud del sistema de ficheros y revisaron la latencia del almacenamiento subyacente. El incidente se mantuvo contenido a un pequeño conjunto de usuarios y el rendimiento se normalizó tras las reconstrucciones.

No fue glamuroso. Ninguna tecnología nueva. Pero la disciplina aburrida—probar restauraciones, mantener runbooks y muestrear la salud de buzones—les permitió reconocer el modo de fallo temprano y no malgastar tiempo cambiando ajustes no relacionados.

Errores comunes (síntoma → causa raíz → solución)

Esta es la parte donde dejamos de fingir que cada entorno es único. Estos patrones se repiten entre empresas porque las personas se repiten entre empresas.

1) Síntoma: el login tarda 2–10 segundos, luego todo va bien

Causa raíz: backend de auth lento (LDAP/SQL), caché de auth ausente o ráfagas de handshake TLS saturando imap-login.
Solución: habilitar auth_cache_size/auth_cache_ttl, verificar latencia del backend, aumentar service imap-login process_limit solo si la CPU puede soportarlo.

2) Síntoma: abrir carpetas es lento, pero fetch del cuerpo está bien

Causa raíz: latencia I/O de índices o reconstrucciones de índices; también común con almacenamiento de metadata de alta latencia.
Solución: mover índices a almacenamiento más rápido vía mail_index_path, investigar triggers de corrupción de índices, verificar opciones de montaje y latencia del sistema de ficheros.

3) Síntoma: LIST/STATUS es lento en muchas carpetas

Causa raíz: demasiados buzones + consultas de status costosas, cliente solicitando STATUS para cada carpeta o latencia en namespaces/mounts remotos.
Solución: asegurarse de que los índices estén sanos, considerar cambios de política en clientes, evitar almacenamiento remoto con latencia para workloads intensivos en Maildir.

4) Síntoma: SEARCH hace que el servidor “se congele”

Causa raíz: sin FTS y escaneos por fuerza bruta; o indexación FTS compitiendo con IMAP por I/O.
Solución: implementar FTS correctamente (almacenamiento aislado, indexación limitada) o limitar búsquedas y manejar expectativas.

5) Síntoma: picos aleatorios, p99 terrible, medias parecen bien

Causa raíz: jitter de almacenamiento, encolamiento, demasiada concurrencia, compactación/reconstrucción periódica de índices.
Solución: medir await de I/O y profundidad de cola, dimensionar límites de procesos, y abordar la capa de almacenamiento primero.

6) Síntoma: se vuelve más lento después de “afinar” aumentando concurrencia

Causa raíz: aumentaste I/O paralelo más allá de lo que el almacenamiento puede servir con baja latencia.
Solución: reducir el número de workers; afinar para latencia, no para máximo throughput; aislar índices en medios más rápidos.

Broma #2: Añadir más procesos IMAP a un disco lento es como abrir más cajas en la caja registradora cuando solo hay un cajero.

Tareas prácticas: comandos, significado de la salida y la decisión que tomas

Querías tareas reales. Aquí tienes más de una docena, cada una con un comando, salida de ejemplo, qué significa y qué haces después. Ejecútalos en orden cuando estés de guardia y cansado.

Task 1: Confirma la versión de Dovecot y componentes habilitados

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

Qué significa: Estás en la línea 2.3.x. Algunos knobs y valores por defecto difieren según la versión.

Decisión: No apliques consejos escritos para 1.x/2.0 a ciegas. Mantén tu tuning dentro de las capacidades y defaults de la versión.

Task 2: Vuelca la configuración efectiva (no lo que crees que configuraste)

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

Qué significa: Estás en Maildir, con límites de proceso altos y caché de auth desactivada.

Decisión: Marca esto como “probable presión de metadata de almacenamiento” más “el backend de auth puede estar caliente”. Ahora sabes qué perillas están realmente en efecto.

Task 3: Comprueba conteos de conexiones actuales y si hay colas

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

Qué significa: Las sesiones activas son visibles. Si esta lista es enorme y estable, tienes muchas conexiones concurrentes (IDLE, móviles).

Decisión: Si las conexiones son altas, verifica límites de procesos y memoria. Si los usuarios se quejan de logins durante picos, imap-login puede estar saturado.

Task 4: Comprueba carga del sistema, iowait y cola de ejecución rápidamente

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

Qué significa: La carga es alta. La carga por sí sola no prueba saturación de CPU; incluye tareas esperando I/O.

Decisión: Revisa inmediatamente iowait y latencia de disco. Carga alta + CPU baja suele indicar I/O.

Task 5: Identifica latencia de I/O y saturación (el culpable habitual)

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

Qué significa: md0 está casi saturado (%util ~95) con alto await (~36 ms). Eso es latencia visible para usuarios en workloads intensivos en stat/índice.

Decisión: Trata la latencia de almacenamiento como prioridad #1. Reducir concurrencia puede mejorar la latencia cola inmediatamente; la solución a largo plazo es diseño de almacenamiento.

Task 6: Detecta problemas de latencia a nivel de sistema de ficheros y opciones de montaje

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

Qué significa: ext4 con opciones por defecto. Está bien, pero no necesariamente óptimo para tu patrón de correo.

Decisión: No cambies opciones de montaje en producción al azar para cazar rendimiento sin entender el impacto en durabilidad. Mide el coste de fsync y el churn de índices primero.

Task 7: Mide la utilización de procesos Dovecot y si haces fork demasiado

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

Qué significa: Workers IMAP activos; login y auth también muestran CPU. Si ves muchos procesos de corta vida, puedes estar manejando tormentas de reconexión.

Decisión: Si login/auth es alto durante quejas, prioriza caché de auth e investigación de latencia del backend.

Task 8: Comprueba DNS que afecte auth o TLS (asesino silencioso)

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

Qué significa: Tienes dos servidores DNS configurados. Si uno es lento o está muerto, algunas búsquedas pueden estancarse.

Decisión: Si logins lentos se correlacionan con timeouts DNS en syslog, arregla DNS primero. No afines Dovecot alrededor de una tubería rota.

Task 9: Revisa logs de Dovecot por reconstrucciones o pistas de corrupción de índices

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

Qué significa: Se están haciendo reconstrucciones de índices bajo carga de usuario y el locking de FTS está expirando. Eso se sentirá como lentitud y bloqueos “aleatorios”.

Decisión: Investiga por qué los índices se corrompen o entran en lock. Considera reubicar índices, revisar permisos y evaluar latencia/semánticas de locking del almacenamiento.

Task 10: Verifica formato de buzón y cuenta ficheros (chequeo de dolor Maildir)

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

Qué significa: ~186k ficheros para un solo usuario (incluyendo índices, tmp, cur/new). Eso es mucho metadata.

Decisión: Si muchos usuarios son así y la latencia de almacenamiento es notable, Maildir será un problema recurrente. Considera mdbox/sdbox o reubicar índices y mantenimiento agresivo.

Task 11: Mide tiempos IMAP por comando desde el servidor (rápido y sucio)

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

Qué significa: Abrir INBOX tomó 412 ms desde la perspectiva del servidor. Eso ya está en territorio donde el usuario lo nota.

Decisión: Enfócate en el coste de abrir índices y la latencia de almacenamiento. Si las aperturas son lentas, FETCH también lo será, solo con síntomas diferentes.

Task 12: Inspecciona ubicaciones y tamaños de índices de 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

Qué significa: La caché de índice es 50 MB para ese buzón. No es automáticamente malo, pero es mucho I/O si se reescribe constantemente.

Decisión: Si los índices están en almacenamiento lento, muévelos. Si hay corrupción/reconstrucción, investiga la causa subyacente antes de cambiar tamaños de caché.

Task 13: Comprueba latencia del backend de auth (ejemplo con SQL; adapta a 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

Qué significa: ~482 ms para completar una prueba de auth. Eso es demasiado lento si los clientes se reconectan con frecuencia.

Decisión: Habilita caché de auth y arregla el rendimiento del backend (índices en SQL, tuning LDAP, ruta de red). Si el backend es remoto, la latencia aparecerá como “IMAP lento”.

Task 14: Confirma si alcanzas límites de descriptores de fichero

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

Qué significa: Límite soft 1024 puede ser demasiado bajo para un servidor IMAP ocupado con muchas conexiones concurrentes y archivos Maildir.

Decisión: Aumenta límites vía overrides de systemd o la configuración de init apropiada. Si alcanzas límites, tendrás fallos y reintentos que parecen lentitud.

Task 15: Comprueba si el servidor está haciendo swap (al correo le disgusta el swap)

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

Qué significa: Estás usando swap. Eso convierte “a veces lento” en “todo lento”, especialmente bajo ráfagas de conexión.

Decisión: Reduce concurrencia, añade RAM, arregla fugas de memoria y detén el swapping. Si debes recurrir al swap, ya estás en modo supervivencia.

Task 16: Confirma si IMAP está limitado por handshakes 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))

Qué significa: Muchas conexiones establecidas están en imap-login brevemente durante el handshake/auth antes de pasar a manooff.

Decisión: Si los procesos imap-login están al límite durante picos, ajusta process_limit para imap-login y asegura CPU disponible. También reduce patrones de reconexión cuando sea posible (configuración de cliente, comportamiento del balanceador).

Listas de verificación / plan paso a paso

Checklist A: “IMAP está lento ahora mismo” (30 minutos)

Identifica qué está lento: login vs LIST vs SELECT vs FETCH vs SEARCH (pregunta a un usuario afectado por el comportamiento exacto).
Ejecuta doveconf -n para capturar ajustes efectivos (guarda la salida en las notas del incidente).
Comprueba latencia de almacenamiento con iostat -x. Si await está alto, deja de afinar Dovecot y trata el almacenamiento como cuello de botella.
Revisa logs de Dovecot por mensajes de reconstrucción/corrupción de índices.
Comprueba latencia de auth con doveadm auth test y habilita caché de auth si es necesario.
Comprueba conteos de conexión y saturación de imap-login (doveadm who, ss, ps).
Si hay swapping: reduce concurrencia, detén la hemorragia y luego planifica capacidad.

Checklist B: Afinar sin crear un nuevo incidente (1–2 días)

Elige una métrica objetivo: p95 SELECT time, p95 login time o SEARCH time para un buzón representativo.
Mueve índices a almacenamiento rápido si actualmente están co-localizados con buzones lentos. Valida permisos y estrategia de backups.
Implementa auth_cache_size y TTL sensatos; valida comportamiento de cambio de contraseña con los stakeholders.
Dimensiona bien límites de procesos: empieza conservador, luego aumenta hasta que la latencia deje de mejorar.
Decide la estrategia de FTS: implantar correctamente o no implantar. Evita estados medio-configurados.
Verifica resultados con los mismos comandos y un buzón de prueba consistente.

Checklist C: Arreglos estructurales (1–6 semanas)

Evalúa el formato de buzón: si la metadata de Maildir te mata, planifica migración a mdbox/sdbox con plan de rollback.
Repara el almacenamiento: prioriza latencia e IOPS de metadata. Números de throughput no son suficientes.
Implementa gestión de capacidad: límites de descriptores, dimensionamiento de memoria y concurrencia predecible.
Establece ventanas de mantenimiento para reconstrucciones de índices/reindexado FTS para evitar dolor diurno.

Preguntas frecuentes

1) ¿Por qué IMAP está lento cuando la CPU está baja?

Porque IMAP suele estar limitado por latencia de almacenamiento. CPU baja con iowait alto y alto await de disco es clásico. Dovecot pasa tiempo esperando metadata del sistema de ficheros y I/O de índices.

2) ¿Simplemente debería aumentar `service imap { process_limit }`?

Sólo si has demostrado que estás limitado por CPU o por colas en el lado de Dovecot. Si la latencia de almacenamiento es el cuello de botella, más workers puede empeorar la latencia de cola al aumentar la I/O paralela.

3) ¿Maildir es inherentemente lento?

No. Maildir puede ser rápido en almacenamiento local de baja latencia con buen rendimiento de metadata. Se vuelve lento cuando escalas el número de ficheros, usas almacenamiento de alta latencia o creas jerarquías de carpetas enormes que amplifican operaciones de metadata.

4) ¿Cuál es la mejora única más efectiva para la latencia de apertura de carpetas?

Índices sanos en almacenamiento rápido. Eso suele significar reubicar archivos de índice (vía mail_index_path) y detener la causa subyacente de reconstrucciones.

5) ¿Necesito FTS?

Si los usuarios dependen de búsquedas en cuerpo y adjuntos del servidor, sí—impleméntalo correctamente. Si las búsquedas son raras, FTS puede convertirse en piezas móviles adicionales y I/O extra para poco beneficio.

6) ¿Por qué los clientes móviles empeoran todo?

Se reconectan con frecuencia, lo que amplifica costes de login/auth/TLS y aumenta churn de concurrencia. Sin caché de auth y sin suficiente capacidad en imap-login, obtendrás tormentas periódicas de “correo lento”.

7) ¿Cómo sé si los índices se están corrompiendo?

Los logs mencionarán reconstrucción de archivos de índice o archivos cache/index corruptos. Los usuarios pueden ver aperturas de carpetas lentas y listas de mensajes inconsistentes. Confírmalo revisando logs y con operaciones doveadm dirigidas.

8) ¿Los ajustes TLS realmente pueden causar lentitud IMAP?

Sí, especialmente si tienes tormentas de conexiones o procesos imap-login infra-provisionados. El coste del handshake TLS se hace visible cuando se multiplica por muchas reconexiones.

9) ¿Qué pasa si SEARCH es lento pero todo lo demás está bien?

Eso suele ser “sin FTS” o “FTS no al día”. Decide si invertir en indexación de búsqueda. Si no, SEARCH seguirá siendo una operación costosa por diseño.

Siguientes pasos que puedes ejecutar esta semana

Ejecuta la guía de diagnóstico rápido y captura evidencia: doveconf -n, iostat -x, extractos relevantes de logs y una prueba cronometrada con doveadm fetch.
Si la latencia de almacenamiento es alta, trátala como el problema raíz. Reduce concurrencia para bajar la contención y empieza a planificar mover índices a medios más rápidos.
Habilita caché de autenticación si tienes cualquier backend de auth remoto y un porcentaje significativo de usuarios móviles. Ajusta TTLs para no sorprender a seguridad.
Dimensiona límites de procesos con datos: aumenta hasta que la latencia deje de mejorar y luego para. “Maximizar” workers es la forma de maximizar incidentes.
Toma una decisión clara sobre búsqueda: implementa FTS correctamente (recursos aislados, indexación controlada) o acepta SEARCH más lento y evita desestabilizar el sistema.
Añade salvaguardas: límites de descriptores, evitar swap y métricas ligeras que indiquen si estás limitado por auth, índices o almacenamiento.

Si solo haces una cosa: mide latencia de I/O y salud de índices antes de cambiar ajustes. La mayoría del “tuning” de Dovecot es en realidad ingeniería de almacenamiento y disciplina operacional con forma de correo.