Mail stops flowing. The deferred queue grows. CPU is low, network paths are healthy, and DNS resolves fine. You run postqueue -p and see tens of thousands of messages in the active queue. The queue manager has hit qmgr_message_active_limit and cannot schedule new deliveries.
This is head-of-line blocking by design. The active queue has a hard ceiling (default 20,000 messages). Once reached, the queue manager stops scanning both the incoming and deferred queues. No new messages enter active delivery until an existing one is delivered or deferred. The system does not degrade gradually; it works, then it stops.
The most common cause is a single slow or failing destination consuming a disproportionate share of active queue slots. Postfix uses fair scheduling across destinations, not priority scheduling. Messages to a slow destination occupy slots until they time out or succeed, starving messages to healthy destinations. The fix is rarely “raise the limit.” The fix is to identify and isolate the destination monopolizing the queue.
What this means
The active queue holds messages eligible for delivery right now. The queue manager (qmgr) maintains queue entry metadata in memory and schedules delivery attempts against it. qmgr_message_active_limit caps how many messages can be in the active queue simultaneously. The default is 20,000 and has been stable across Postfix versions.
When the active queue is full, qmgr stops accepting new messages into it. Messages accumulate in the incoming and deferred queues instead. This is not a crash or a hang. The queue manager is functioning as designed: a fixed cap on how many messages qmgr can manage at once.
flowchart TD
A["Incoming + Deferred queues"] -->|"qmgr scans"| B["Active queue\n(cap: 20000)"]
B -->|"slot"| C["Healthy dest delivery\n(fast, slot freed)"]
B -->|"slot"| D["Slow dest delivery\n(times out, slot held)"]
D -->|"accumulates"| E["Active queue fills\nwith slow-dest messages"]
E -->|"limit reached"| F["qmgr stops scanning\nincoming + deferred"]
F -->|"result"| G["All delivery stalls\nregardless of dest health"]The degradation is cliff-edge. Throughput remains normal until the limit is hit, then drops sharply because new messages cannot enter the delivery pipeline.
This is distinct from incoming-queue growth, which indicates content filter or Milter backpressure. If your incoming queue is large but your active queue is small, you have a filter problem, not active queue saturation.
Common causes
| Cause | What it looks like | First thing to check |
|---|---|---|
| Slow destination monopolizing slots | Active queue near limit; deferred growing for one domain; other domains stalled | qshape active or log analysis for the dominating domain |
| Destination rate limiting or greylisting | High deferral rate with 4xx codes (e.g. “4.7.1 rate limited”) for specific domains | Deferred log entries grouped by destination domain |
| Limit too low for traffic volume | Active queue frequently near limit with diverse, healthy destinations | Compare active queue size against the limit during peak hours |
| Queue file corruption | qmgr logging errors or panics; postqueue -p slow or inconsistent | `grep -iE ’error |
Quick checks
Safe, read-only operations. Run in order to confirm the diagnosis.
# Check current active queue size vs configured limit
# Postfix uses hash subdirectories (0-9, A-F), so use find, not ls
find /var/spool/postfix/active -type f | wc -l
postconf -h qmgr_message_active_limit
# Compute utilization ratio
ACTIVE=$(find /var/spool/postfix/active -type f | wc -l)
LIMIT=$(postconf -h qmgr_message_active_limit)
echo "Active: $ACTIVE / $LIMIT ($(( ACTIVE * 100 / LIMIT ))%)"
# Identify which destination domain dominates the active queue
qshape active | head -20
# Identify which destination domain dominates deferred entries
grep 'status=deferred' /var/log/mail.log | awk -F'to=<|>,' '{print $2}' | cut -d@ -f2 | sort | uniq -c | sort -rn | head
# Check qmgr responsiveness under load
time postqueue -p > /dev/null
# Check for clog warnings (destination consuming active queue slots)
grep 'using up.*active queue' /var/log/mail.log | tail -10
# Check qmgr CPU usage
ps -eo pid,pcpu,rss,comm | grep qmgr
# Verify recipient limit is not silently overriding your active limit
postconf -h qmgr_message_active_limit qmgr_message_recipient_limit
The qshape tool is the canonical Postfix diagnostic for queue shape analysis. qshape active shows the active queue broken down by recipient domain, making it immediately obvious which destination is consuming slots. If the total at the bottom of the qshape output is below your qmgr_message_active_limit, the active queue is not yet saturated and you should look elsewhere.
The clog warning, controlled by qmgr_clog_warn_time (default 300 seconds), looks like: warning: mail for example.com is using up N of M active queue entries. This is Postfix’s built-in early warning for this condition. If you have set qmgr_clog_warn_time = 0, you have disabled the primary early-warning signal. Re-enable it.
How to diagnose it
Confirm the active queue is at or near the limit. Compare the filesystem count against
postconf -h qmgr_message_active_limit. Above 80% sustained for more than 10 minutes is a warning condition. Above 95% is critical.Identify the consuming destination. Use
qshape activeto see per-domain breakdown. Cross-reference with deferred log analysis to confirm which destination is both failing deliveries and occupying active slots. A single domain accounting for the majority of active queue entries is your culprit.Verify destination health. Test connectivity to the problem destination’s MX hosts directly. Check whether deferral reasons are timeouts (network or capacity), 4xx rate limiting (destination throttling you), or DNS-related (resolver issues affecting that domain specifically).
Check qmgr CPU. If qmgr CPU is high while delivery rate is low, the queue manager is struggling with scheduling overhead. This compounds the problem because scheduling decisions take longer, reducing effective throughput.
Check system memory. qmgr maintains queue entry metadata in memory for each active message. If you are considering raising
qmgr_message_active_limit, verify the system has enough RAM. There is no documented per-entry memory cost, but qmgr memory usage grows with queue depth and the OOM killer is a real risk at elevated limits.Rule out filter backpressure. Check whether the incoming queue is also growing. If incoming is large and active is small, you have a content filter or Milter problem, not active queue saturation.
Metrics and signals to monitor
| Signal | Why it matters | Warning sign |
|---|---|---|
| Active queue size vs limit ratio | Direct measure of proximity to the cliff | Sustained above 70% of qmgr_message_active_limit |
| Per-destination deferred count | Identifies which destination is consuming active slots | One domain dominating deferred entries |
| Deferred queue growth rate | Confirms active accumulation vs transient blip | Sustained positive growth over multiple hours |
| qmgr CPU utilization | High CPU means scheduler is struggling | Rising CPU with flat or declining delivery rate |
| Delivery rate vs injection rate | Shows whether the system is draining | Injection exceeding delivery over sustained window |
postqueue -p response time | Proxy for qmgr health under load | Consistently above 5 seconds |
| Clog warning log entries | Postfix’s built-in saturation signal | Any “using up N of M active queue entries” warning |
Fixes
Reduce destination concurrency for the problem domain
If a specific destination is consuming active queue slots because connections time out or the destination is rate-limiting you, reduce the concurrency for that transport. This limits how many simultaneous delivery attempts Postfix makes to that destination, freeing slots for other destinations.
# Global smtp concurrency reduction (affects all destinations - use with caution)
postconf -e 'smtp_destination_concurrency_limit=5'
postfix reload
For per-destination control, use transport maps to route the problem domain through a dedicated transport with its own concurrency limit. This is more surgical and avoids impacting healthy destinations.
Tradeoff: lower concurrency means slower delivery to that destination, but it prevents that destination from monopolizing the active queue. This is almost always the right tradeoff during an incident.
Hold the problem destination’s mail temporarily
If the destination is completely unreachable and you need to unblock other mail immediately, hold messages to that destination. Held messages leave the active queue and enter the hold queue, freeing slots for other traffic.
# Hold messages matching a specific domain pattern
# WARNING: This greps file contents across the entire deferred queue.
# Test the pattern on a small sample first to avoid holding unintended messages.
find /var/spool/postfix/deferred -type f -exec grep -l '@problem.domain' {} \; | xargs -r postsuper -h
Tradeoff: held messages require manual release with postsuper -H once the destination recovers. This is a targeted intervention, not a permanent fix. Verify the grep pattern carefully before running on production queues.
Do NOT flush the deferred queue
Flushing the entire deferred queue (postqueue -f or postsuper -r ALL) during active queue saturation makes the problem worse. You are force-feeding messages back into a queue that is already at capacity. The deferred messages re-enter the active queue, consume slots, and accelerate the gridlock.
Flush individual destinations only after you have addressed the root cause and confirmed the destination is healthy.
Raise qmgr_message_active_limit (last resort)
Increasing the limit gives the queue manager more slots to work with, but it increases memory pressure on qmgr and does not address the root cause. If a slow destination is monopolizing the queue, a higher limit just means more messages pile up before the cliff hits.
# Check current values first
postconf -h qmgr_message_active_limit qmgr_message_recipient_limit
# Raise the limit
postconf -e 'qmgr_message_active_limit=40000'
postfix reload
postfix reload is sufficient - qmgr(8) documents it as the way to apply main.cf changes to the persistent queue manager.
qmgr_message_recipient_limit should not be set lower than qmgr_message_active_limit: if it is, Postfix automatically raises it to match at qmgr startup (and logs a warning), so your lower recipient-limit setting is ignored.
Prevention
- Monitor the active queue utilization ratio continuously. Track
active_queue_count / qmgr_message_active_limitas a time series. Alert at 70% sustained. Treat 90% as an emergency. Keep normal operation below 50%. - Set per-destination concurrency limits proactively. For known slow or high-volume destinations, configure transport-specific concurrency limits before they become a problem.
- Keep
qmgr_clog_warn_timeat its default (300s). Do not disable clog warnings. They are the only built-in signal that a specific destination is saturating the active queue. - Separate problematic traffic via transport maps. If you have a chronically slow destination (bulk mailer, rate-limited partner), route it through a separate transport with its own concurrency and timeout settings.
- Monitor per-destination deferred counts. Knowing which destinations are accumulating deferred entries gives you early warning before those entries monopolize the active queue.
- Track qmgr CPU alongside active queue size. If qmgr CPU rises with queue depth, the scheduler is under pressure. This is a leading indicator that you are approaching the operational ceiling of your current configuration.
How Netdata helps
- Per-second active queue metrics show the utilization ratio trending toward the limit in real time. Correlating active queue growth with deferred queue growth and per-destination delivery rates pinpoints the consuming destination without manual log parsing.
- qmgr CPU tracking alongside queue depth distinguishes capacity exhaustion from a simple slow-destination stall.
- Deferred queue growth rate computed from filesystem counts provides the derivative signal that matters. A growing deferred queue is the leading indicator for active queue saturation.
- Injection vs delivery rate correlation makes it visible when the system stops draining, even if the active queue has not yet hit the hard limit.
- Anomaly detection on queue sizes surfaces unusual growth patterns before they cross static thresholds, which matters for the cliff-edge failure mode where there is no gradual degradation to catch.