Re: sender_bcc_maps and performance
- On Wed, Jul 01, 2009 at 02:48:00PM +0200, Rocco Scappatura wrote:
> Hello,What fraction of your traffic is sent by these 2 entries. Do you have
> I have enabled "sender_bcc_maps" in my main.cf. The lookup file has just
> 2 entries.
content filters downstream of the cleanup service that adds the bcc
addresses? Report your configuration:
> I have noticed that the number of message in active queue grews as soonYour observations are flawed, this processing happens before the message
> as I enable this feature.
enters the active queue, so more latency upstream would actually reduce
the size of the active queue unless you significantly increase the
number of output messages per input message, which suggests a misconfigured
content filter or similar.
Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.
To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.
- Thanks Victor,
>A neglegible one. Yes, I have set up a content filter (amavisd-new).
> On Wed, Jul 01, 2009 at 02:48:00PM +0200, Rocco Scappatura wrote:
> > Hello,
> > I have enabled "sender_bcc_maps" in my main.cf. The lookup file has
> > 2 entries.
> What fraction of your traffic is sent by these 2 entries. Do you have
> content filters downstream of the cleanup service that adds the bcc
> addresses? Report your configuration:
Anyway, here is my postconf output:
alias_maps = hash:/etc/aliases
anvil_rate_time_unit = 60s
bounce_size_limit = 1
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
default_process_limit = 150
html_directory = no
inet_interfaces = $myhostname, localhost
local_recipient_maps = unix:passwd.byname $alias_maps
mail_owner = postfix
mail_spool_directory = /var/spool/mail
mailq_path = /usr/bin/mailq
manpage_directory = /usr/local/man
message_size_limit = 35840000
minimal_backoff_time = 1800s
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
mydomain = av2.sttspa.it
myhostname = av2.sttspa.it
mynetworks = /etc/postfix/relayzahra2
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases
proxy_read_maps = $local_recipient_maps $mydestination
$virtual_alias_maps $virtual_alias_domains $virtual_mailbox_maps
$virtual_mailbox_domains $relay_recipient_maps $relay_domains
$canonical_maps $sender_canonical_maps $recipient_canonical_maps
$relocated_maps $transport_maps $mynetworks
queue_directory = /var/spool/postfix
readme_directory = no
relay_domains = proxy:mysql:/etc/postfix/mysql-relay-domains.cf
sample_directory = /etc/postfix
sender_bcc_maps = hash:/etc/postfix/sender_bcc
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
smtp_connect_timeout = 30s
smtpd_banner = $myhostname
smtpd_client_connection_count_limit = 50
smtpd_client_connection_rate_limit = 100
smtpd_client_event_limit_exceptions = <list of IPs>
smtpd_client_message_rate_limit = 60
smtpd_client_recipient_rate_limit = 250
smtpd_client_restrictions = check_client_access
smtpd_recipient_restrictions = check_client_access
reject_invalid_hostname reject_rbl_client zen.spamhaus.org
smtpd_sasl_auth_enable = yes
smtpd_sender_restrictions = check_sender_access
strict_rfc821_envelopes = yes
transport_maps = proxy:mysql:/etc/postfix/mysql-transport.cf
unknown_local_recipient_reject_code = 550
unverified_recipient_reject_code = 550
> > I have noticed that the number of message in active queue grews asreduce
> > as I enable this feature.
> Your observations are flawed, this processing happens before the
> enters the active queue, so more latency upstream would actually
> the size of the active queue unless you significantly increase theOK. I have applied configuration updating during a congested moment.. I
> number of output messages per input message, which suggests a
> content filter or similar.
fear that this has increased congestion as result.
Then I have rolled back modifications and all (slowly) have returned to
Finally, I have applied again configuration modification (which uses
'sender_bcc_maps') yesterday night and tomorrow all works fine without
(at least at the moment) active queue congestion.
What it could be happen?