Queue too large

Four relays bogged down with massive queues due to a common destination
failure. Of the four the first two serve multiple purposes
(DNS/FTP/mail relay) the later two are only relays. Once we addressed
the destination relay issue (an anti-spam device that failed) I started
to work on the external relays. The later two relay queues got worked
down to zero within a day. The first two however are still massive.
Since the queue procesing seems to hamper the performace of the other
services we stopped processing on the first server (which has the ftp
server). The second progresses however at a slow rate.

My questions is two fold. First, is there a way to more quickly process
the queue. Second, can I set one of the later two (low queue) relays
as a fallback_relay to hasten the queue processing on the loaded
relays.



<four external relays> ----> load balancer (VIP)-----> <anti spam
relay> ----> <bridge head>

Of the external relays the first two are runnign OSX 10.3 and the
second two are running OSX 10.4, All patched to the latest.

always_bcc =
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
default_destination_concurrency_limit = 100
default_process_limit = 200
enable_server_options = yes
fallback_relay = smtp4.xyz.com
inet_interfaces = all
luser_relay =
mail_owner = postfix
mailbox_transport = cyrus
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
maps_rbl_domains =
relays.ordb.org,opm.blitzed.org,list.dsbl.org,sbl. spamhaus.org,cbl.abuseat.org,dul.dnsbl.sorbs.net

message_size_limit = 15360000
minimal_backoff_time = 300s
mydestination = $myhostname,localhost.$mydomain,smtp2.xyz.com
mydomain_fallback = localhost
myhostname = smtp2.xyz.com
mynetworks =
127.0.0.1/32,10.0.0.0/8,149.111.0.0/16,161.249.0.0/16,172.30.36.0/24,65.168.73.0/24

mynetworks_style = host
newaliases_path = /usr/bin/newaliases
qmgr_message_active_limit = 40000
queue_directory = /private/var/spool/postfix
queue_run_delay = 300s
readme_directory = /usr/share/doc/postfix
relay_domains = hash:/etc/postfix/relay_domains
relayhost =
sample_directory = /usr/share/doc/postfix/examples
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
smtpd_client_restrictions = permit_mynetworks warn_if_reject
reject_maps_rbl
smtpd_enforce_tls = no
smtpd_pw_server_security_options = none
smtpd_recipient_restrictions =
permit_mynetworks,reject_unauth_destination
smtpd_sasl_auth_enable = no
smtpd_tls_loglevel = 0
smtpd_use_pw_server = no
smtpd_use_tls = no
transport_maps = hash:/etc/postfix/transport
unknown_local_recipient_reject_code = 450

hphinizy3@gmail.com wrote:
> Four relays bogged down with massive queues due to a common destination
> failure.


default_destination_concurrency_limit = 100
seems awfully high; 4 servers X 100 delivery processes to a single
destination?

What I'd probably do is, on the loaded-up critical server, add a temporary
transport entry (or relayhost) entry, to dump all the email onto one
or more of the other less loaded and non-essential mail relays, and let them
chug away at delivering the mail.

--
Greg

Greg Hackney wrote:
> hphinizy3@gmail.com wrote:
> > Four relays bogged down with massive queues due to a common destination
> > failure.
>
>
> default_destination_concurrency_limit = 100
> seems awfully high; 4 servers X 100 delivery processes to a single
> destination?
>
> What I'd probably do is, on the loaded-up critical server, add a temporary
> transport entry (or relayhost) entry, to dump all the email onto one
> or more of the other less loaded and non-essential mail relays, and let them
> chug away at delivering the mail.
>
> --
> Greg

If I add:
fallback_relay = <ip address of the other relay>

Will that act sufficiently to move the deferred off the loaded relay
onto the good relays? Simply adding to the transport is the same as
letting the relay send to the current destination, no? Either way,
whether it is the proper destination (anti-spam device) or one of its
relay peers I still have to wait for the queue to clear.

Thanks

hphinizy3@gmail.com wrote:

> If I add:
> fallback_relay = <ip address of the other relay>
>
> Will that act sufficiently to move the deferred off the loaded relay
> onto the good relays?


Probably not. The fallback_relay is used when the destination is not found
or is unreachable. In your case, it sounds like the remote site is reachable,
but is busy from all the load.


> Simply adding to the transport is the same as
> letting the relay send to the current destination, no?

No. I though that your objective was to clear all the email
from your FTP server and move it onto your other relays. If
so, on the FTP server, you can temporarily add your other server
as a relayhost, or, you can add an entry in the transport file
for the domain in question, routing it via your other systems
(not directly to the remote destination).


--
Greg

You are correct, this would do the trick however, how is this faster
than letting the mail server work through its queue (8GB of mail mostly
in incoming and defer) via the existing transport medium... In either
case, I am looking at postfix working its way through 8GB of mail... It
either sends to one of the other relays or, it sends to the current
destination (that being the anti-spam device) queue drops a the same
rate regardless.

If I add the fallback_relay to main.cf the mail server will attempt to
send it to the anti-spam device and if that fails it will pass it off
to the fallback relay. This should increase the rate at which the mail
queue is dealt with. What I am looking to do is hasten the whole
process... Example, on another relay we had 5.8 GB of mail this
morning only to see that shrink to 5.5 GB by mid afternoon... A
pedestrian pace.

Regards

Greg Hackney wrote:
> hphinizy3@gmail.com wrote:
>
> > If I add:
> > fallback_relay = <ip address of the other relay>
> >
> > Will that act sufficiently to move the deferred off the loaded relay
> > onto the good relays?
>
>
> Probably not. The fallback_relay is used when the destination is not found
> or is unreachable. In your case, it sounds like the remote site is reachable,
> but is busy from all the load.
>
>
> > Simply adding to the transport is the same as
> > letting the relay send to the current destination, no?
>
> No. I though that your objective was to clear all the email
> from your FTP server and move it onto your other relays. If
> so, on the FTP server, you can temporarily add your other server
> as a relayhost, or, you can add an entry in the transport file
> for the domain in question, routing it via your other systems
> (not directly to the remote destination).
>
>
> --
> Greg