Hi,
I run a moderately busy mail server (postfix + dovecot + amavis).
Every day, during peak times (around 10am to 2pm), we see delays in
the delivery of mail (both incoming and outgoing) of around 5 to 10
minutes. I appreciate this isn't a big delay, but I'm getting
frustrated trying to figure out the cause.
High system load would be the obvious answer, but the server doesn't
appear to be under much load during these periods:
# vmstat 15 -S m
procs -----------memory---------- ---swap-- -----io---- -system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
0 0 0 1476 19 719 0 0 208 247 1 1 11
6 82 1
1 0 0 1550 19 720 0 0 50 336 495 912 20
20 58 2
1 0 0 1495 19 721 0 0 69 201 425 782 11
15 70 4
0 0 0 1505 19 723 0 0 138 276 535 888 19
17 62 3
2 0 0 1498 19 726 0 0 50 347 486 929 26
22 49 2
0 0 0 1478 20 725 0 0 42 381 460 814 46
21 32 1
0 0 0 1482 20 717 0 0 97 608 477 775 35
17 46 2
2 0 0 1479 20 717 0 0 320 285 563 858 19
19 60 2
Amavis + SpamAssassin + ClamAV are being used for scanning mail
(incoming only). Again, this would be a likely source of delay, but
amavis never reaches its max connections (we typically only see half
this figure). I've also enabled verbose logging in amavis, and it
never takes longer than a few seconds to scan mail.
Looking at the delays=a/b/c/d part of the postfix logs, the delays are
almost always in part b, which I understand is the queue manager.
# postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
delay_warning_time = 4h
dovecot_destination_recipient_limit = 1
inet_interfaces = all
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
message_size_limit = 20000000
mydestination = xxxxx, xxxxx, localhost, xxxxx
myhostname = mail1.lark-uk.com
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 xxxxx
myorigin = /etc/mailname
readme_directory = no
receive_override_options = no_address_mappings
recipient_delimiter = +
relay_domains = xxxxxx
relay_recipient_maps = hash:/etc/postfix/relay_recipient_maps
relayhost =
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP
smtpd_recipient_restrictions =
permit_mynetworks,permit_sasl_authenticated, check_recipient_access
hash:/etc/postfix/access, reject_unauth_destination, reject_rbl_client
bogons.cymru.com
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_tls_CAfile = /etc/ssl/certs/intermediate.crt
smtpd_tls_auth_only = no
smtpd_tls_cert_file = /etc/ssl/certs/xxxxx.com-2013-with-intermediate.crt
smtpd_tls_key_file = /etc/ssl/certs/xxxxx.com-2013-with-intermediate.crt
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
transport_maps = hash:/etc/postfix/transport
virtual_alias_maps =
mysql:/etc/postfix/mysql-virtual-alias-maps.cf,mysql:/etc/postfix/mysql-email2email.cf
virtual_mailbox_domains =
mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf
virtual_transport = dovecot
If the server was overloaded, I'd happily accept these short delays in
mail delivery; but it seems odd that they happen even though the
server is pretty idle.
Any ideas please?
Thanks,
Peter Smith
