 |
| Prev-20 | Home | Next-20 |
| Prev-20 | Home | Next-20 |
| Prev-Msg | Prev-Thread | Postfix-users | Sep-2007 | Next-Thread | Next-Msg |
| Subject: | Postfix 'too nice' with content_filter |
| Group: | Postfix-users |
| From: | Mauro Calderara |
| Date: | 19 Sep 2007 |
We're seeing something here that we did not expect but I cannot tell
whether this is intentional from postfix' side or not. I hope it is a
postfix
issue at all.
We are running the system on a normal Debian Etch Installation, see
below for what that means in terms of Versions.
This is the issue in short:
During times of more intense use of our mailserver in terms of
incoming mails, it can happen that the content_filter is not able to
keep up with the incoming mail and thus mails get queued. So far so
good, that was to expect. Yet the CPU is rather idle, probably
because the slower of the filters (SA) is doing DNSlookups.
So what we would like to do, is increase the level of concurrency on
the filters. That level always drops down to 2 (because, as I
believe, postfix considers the content_filter too slow for more).
This seems to be independent of the number of available processes
involved, from postfix-side as well as from filter-side. Yet we would
still like to increase the concurrency because then the slow
DNSlookups or whatever it is work in parallel, thus bringing
hopefully more total throughput.
initial_destination_concurrency only works for the purpose and for
very short time after postfix reload, then drops back to 2.
I've read the tuning-docs and the qshape-readme as well, yet I am not
sure what to do. Maybe I just didn't see the obvious?
Configuration is stated much further below.
This is the more detailed story:
We use DSPAM and AMaViS as lmtp/smtp-filters, AMaViS also calling
Spamassassin. We feel that DSPAM processes the mail quite fast but
AMaViS is not always that fast, probably due to the DNSlookups
Spamassassin performs taking some time even though we have quite a
big dns-cache installed for the mailsystem. This might lead to more
or less constant time for mail scanning for AMaViS (I think). As this
is not a CPU-intensive task, the system "idles". The idea now was to
increase the level of concurrency for the scanning, but we did not
manage postfix to cooperate in this yet. It turns out that
independent on how many processes we define for smtpd, AMaViS/
Spamassassin, DSPAM or the lmtpd (which feeds mail to DSPAM, feeding
it to AMaViS), there are always only one or two mails processed
simultaneously by the scanners. That is, only two mails "fed" to
DSPAM at a time. DSPAM does not even show up in top, amavis showing
two processes being used in ps aux | grep amavis
I tried to set initial_destination_concurrency a bit higher. That
works for a few seconds after postfix reload. For a queue which does
not get any new mail, you will see a drop of the number of exactly
initial_destination_concurrency right after postfix reload - which
actually are being processed and delivered - then processing again
slows down to two mails every few seconds.
Is there something like minimum_destination_concurrency?
The background for that question is this thesis: postfix sends mail
to DSPAM for scanning. As DSPAM cannot queue the mail, it will
confirm the operation only after the next hop, that is in our case
AMaViS, has confirmed the delivery. AMaViS actually cannot queue the
mail (from what I can tell) either from what I know. So that one, in
my thesis, waits for the recieving Postfix-Process to accept the
mail. After recieving the OK from the Postfix that takes the scanned
mail, this OK propagates back to the injecting postfix. As processing
can take some time, especially for AMaViS performing the
DNSRBLlookups, the feeding postfix might come to the belief that the
thing it is talking to is rather slow and - as it "tries to be a good
neighbour in the network" - throttles its speed. This is actually not
needed, we prefer amavis being busy scanning and waiting for DNS,
than postfix being too nice and amavis and the DNS-cache being
underused.
Now, this whole theory might be very very wrong, it probably is (how
would you
have a performant Mailsystem using AMaViS then if that was true?).
But I don't know where to start for further tuning. My boss kind of
expects that if I increase the number of AMaViS processes to N, load
will go up to N once I do postqueue -f :)
Thanks in advance for any pointers to relevant documentation or other
hints
mauro
Versions:
postfix 2.3.8
AMaViS (amavisd-new) 2.4.2
Spamassassin 3.1.7
DSPAM 3.6.8
BTW, as you can see we do the infamous before-queue virus filtering.
This was a design goal, so far it has not bitten us. I think that is
not the problem here, though
main.cf:
---------
smtpd_banner = $myhostname ESMTP Postfix with Spamhammer[TM]
biff = no
# DEBUGGING
#
# (IMPORTANT: hard-errors -> temporary-errors -> no mail loss)
soft_bounce=no
# immediatly reject if something is fishy with the HELO or the MAIL FROM
#smtpd_delay_reject = no
# debug only for a list of hosts
#debug_peer_list = your.work.station.here
# appending .domain is the MUA's job.
append_dot_mydomain = no
# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h
myhostname = mx1.obfuscated.tld
mydomain = obfuscated.tld
myorigin = /etc/mailname
mydestination = obfuscated.tld, localhost.obfuscated.tld, localhost
mynetworks = 4.2.2.2/28
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
smtpd_proxy_timeout = 600s
# pass information through the filters to the next smtp
smtp_send_xforward_command = yes
lmtp_send_xforward_command = yes
smtpd_authorized_xforward_hosts = 4.2.2.2
# this is only to turn off the NIS-warnings
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
# global "filtering", for all smtpds
smtpd_data_restrictions=reject_unauth_pipelining
# initial_destination_concurrency testing (default: 2)
initial_destination_concurrency = 20
smtpd_helo_restrictions =
permit_mynetworks,
check_helo_access hash:/etc/postfix/access_lists/helo_access,
warn_if_reject,
permit
#reject_invalid_helo_hostname,
#reject_non_fqdn_helo_hostname,
smtpd_sender_restrictions =
permit_mynetworks,
permit
#reject_unknown_sender_domain,
#reject_non_fqdn_sender,
smtpd_recipient_restrictions =
permit_mynetworks,
reject_unauth_destination,
reject_unauth_pipelining,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
reject_unknown_sender_domain,
check_sender_access hash:/etc/postfix/access_lists/
sender_access,
check_recipient_access hash:/etc/postfix/access_lists/
recipient_access,
check_helo_access hash:/etc/postfix/access_lists/
secondary_mx_access,
check_sender_access hash:/etc/postfix/access_lists/
remote_mta_access,
check_policy_service inet:4.2.2.2:10022
#check_policy_service inet:4.2.2.2:10021 # postfix-policyd
#check_policy_service inet:4.2.2.2:10020 # policyd-weight
#reject_non_fqdn_sender,
#reject_non_fqdn_hostname,
#reject_invalid_hostname,
#reject_unknown_hostname,
header_checks = pcre:/etc/postfix/manual_filters/headers
body_checks = pcre:/etc/postfix/manual_filters/body
mime_header_checks = pcre:/etc/postfix/manual_filters/mime_attachments
relay_domains = mysql:/etc/postfix/mysql/relaydomains-vmail.cf,
mysql:/etc/postfix/mysql/relaydomains-pmail.cf,
mysql:/etc/postfix/mysql/relaydomains-domainaliases.cf
relay_recipient_maps = mysql:/etc/postfix/mysql/rcpts-vmail.cf,
mysql:/etc/postfix/mysql/rcpts-pmail.cf
virtual_alias_maps = pcre:/etc/postfix/domainpointings.pcre, mysql:/
etc/postfix/mysql/ virtual_alias.cf
transport_maps = mysql:/etc/postfix/mysql/transport.cf,
mysql:/etc/postfix/mysql/transport-pmail.cf,
mysql:/etc/postfix/mysql/transport-vmail.cf
master.cf
-----------
smtp inet n - - - 200 smtpd
-o smtpd_client_connection_count_limit=10
-o smtpd_proxy_timeout=1000s
-o smtpd_delay_reject=no
-o smtpd_helo_requierd=yes
-o smtpd_proxy_filter=4.2.2.2:10023
-o transport_maps=
-o virtual_alias_maps=
4.2.2.2:10024 inet n - n - 100 smtpd
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_client_restrictions=
-o smtpd_restriction_classes=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o relay_recipient_maps=
-o smtpd_client_connection_count_limit=0
-o smtpd_client_connection_rate_limit=0
-o
recieve_override_options=no_unknown_recipient_checks,no_header_body_chec
ks
-o body_checks=
-o header_checks=
-o content_filter=pass2spamhammer:[4.2.2.2]:10026
-o relay_transport=smtp:[4.2.2.2]:10025
4.2.2.2:10025 inet n - n - 100 smtpd
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_client_restrictions=
-o smtpd_restriction_classes=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o relay_recipient_maps=
-o smtpd_client_connection_count_limit=0
-o smtpd_client_connection_rate_limit=0
-o
recieve_override_options=no_unknown_recipient_checks,no_header_body_chec
ks, no_address_mappings
-o body_checks=
-o header_checks=
-o transport_maps=
-o virtual_alias_maps=
-o content_filter=pass2spamhammer:[4.2.2.2]:10026
pass2spamhammer unix - - y - 40 lmtp
-o smtp_data_done_timeout=1200
-o smtp_send_xforward_command=yes
-o lmtp_send_xforward_command=yes
-o disable_mime_output_conversion=yes
-o smtp_generic_maps=
-o disable_dns_lookups=yes
-o max_use=20
4.2.2.2:10028 inet n - n - 100 smtpd
-o smtpd_helo_restrictions=
-o smtpd_client_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_restriction_classes=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o smtpd_delay_reject=no
-o smtpd_error_sleep_time=0
-o
recieve_override_options=no_unknown_recipient_checks,no_header_body_chec
ks, no_miters,no_address_mappings
-o body_checks=
-o header_checks=
-o content_filter=
-o relay_recipient_maps=
-o smtpd_end_of_data_restrictions=
-o smtpd_soft_error_limit=1001
-o smtpd_hard_error_limit=1000
-o smtpd_client_connection_count_limit=0
-o smtpd_client_connection_rate_limit=0
The rest of the file being standard
PS: 4.2.2.2 is not our actual IP ,)
| Prev-Msg | Prev-Thread | Postfix-users | Sep-2007 | Next-Thread | Next-Msg |