Dovecot and Linux TCP Stack: Connection Latency under High Concurrency

Connection Hand-off Mechanism

Dovecot does not implement a custom prioritization logic for queued connections; it relies on the Linux kernel's TCP stack to manage the order of arrival. When a burst occurs, the listener process accepts connections from the kernel's accept queue in a First-In-First-Out (FIFO) manner and attempts to hand them off to an available worker process.

Latency and the Process Limit

Yes, the listener mechanism introduces latency when the default_process_limit is reached, even if the TCP backlog is not full. In this scenario, the following sequence occurs:

• The Linux kernel completes the TCP three-way handshake and places the connection in the accept queue.
• The Dovecot listener attempts to accept() the connection.
• If no worker processes are available and the default_process_limit has been hit, the listener cannot spawn a new worker to handle the request.
• The connection remains in the kernel's accept queue until a worker process completes its current task and becomes available to take a new connection.

The latency experienced by the client is the duration the connection spends sitting in the kernel queue waiting for a Dovecot worker to become free. This is distinct from a "connection refused" error, which only occurs once the TCP backlog (somaxconn) is completely exhausted.

Verification and Tuning

To determine if the bottleneck is the Dovecot process limit rather than the OS backlog, use the following scoped commands during a burst:

# Check the Send-Q (the current length of the accept queue) for the IMAP port
ss -lnt | grep :143

If the Send-Q is consistently high while CPU usage is moderate, it indicates that the kernel is holding connections that Dovecot is not accepting fast enough. You can verify if the kernel is dropping connections due to a full backlog with:

# Look for "SYNs to LISTEN sockets dropped"
netstat -s | grep -i "listen"

Assumptions and Constraints

This explanation assumes a standard process-based Dovecot deployment on a modern Linux kernel. Behavior may differ slightly if Dovecot is configured for a threaded model or if an external load balancer is terminating TCP connections before they reach the host.

Missing Diagnostic Detail: Are you observing an increase in TCPBacklog drops in dmesg, or is the latency appearing exclusively as a delay in the initial IMAP greeting?