Huge active queue and system idle, not delivering

classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Huge active queue and system idle, not delivering

Victor Duchovni
On Fri, Jan 08, 2010 at 03:24:25PM +0200, Patrick Chemla wrote:

> When I do  telnet a139.localpc2105.com 25, I get immediate response.

What does "response" mean? Immediate connection completion means
nothing. Do you get a 220 banner right away? Do you get all of
it or just the first line in a multi-line banner, with the
rest arriving later?

> I have checked my local DNS. There were some troubles, and I made some
> improvements. I have now 2 local caching DNS respawning fast. All qmail
> servers addresses are in the postfix /etc/hosts to avoid Ip lookup.
> I have checked qmails servers, nothing has changed since they were able to
> have a queue of 200,000 messages, but they have now a few hundreds only.
> I have calculated average times to complete HELO. All qmails are in the
> same kind of value around 2 minutes.

Why the heck does it take 2 minutes to respond to HELO??? There's
your problem. Fix the qmail servers, to ensure that it takes a few
milliseconds to respond to HELO. Right now your HELO response is 3-4
orders of magnitude too slow.

Fix, probably involves as much removal of tweaks that are
counter-productive as adding specific changes to address the problem
(disable any rate controls that deliberately slow the sender, or
constrain resources).

Start debugging on the qmail side, find out what it is doing for 2
minutes...

--
        Viktor.

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:
<mailto:[hidden email]?body=unsubscribe%20postfix-users>

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.
Reply | Threaded
Open this post in threaded view
|

Re: Huge active queue and system idle, not delivering

Patrick Chemla
In reply to this post by Wietse Venema
Hi,

I will try all your advises, but something still very strange for me:

We see that postfix logs show that ehlo process is very slow through
postfix but very fast by hand. Even I have recorded through
tcpdump/WireShark and I can see that messages are sent very very very
quickly in about 1 second.

But still messages are sent at a rate of a dozen in 10 seconds. That
means that messages are sent 1 by one.

If connexion to qmail servers are slow, or if qmails are mis-parameted,
too slow or anything else, When I do netstat -apn |grep :25 I get only a
few connexions from postfix server to qmail servers. Even if DNS+EHLO
are slow, and more, because DNS+EHLO seem to be slow, why I don't see
hundreds TCP connexions ESTABLISHED ?

I expected that postfix will deliver on 30 qmail servers at the same
time, and should manage hundreds parallel deliveries, hundreds parallel
connexions. Is there some parameter or some conception rule that refrain
him to do so?

I expected that postfix will full up his own CPU/memory creating these
parallel delivery processes or/and will wait after the qmail servers,
but on all servers at the same time, on multiple connections to each one.

Am I correct ? or I am dreaming of another mail transport package?

Patrick

Reply | Threaded
Open this post in threaded view
|

Re: Huge active queue and system idle, not delivering

Patrick Chemla
In reply to this post by Wietse Venema
Hi all,

I got these statistics:

Jan  9 19:15:21 postfix postfix/scache[18038]: statistics: start
interval Jan  9 19:09:03
Jan  9 19:15:21 postfix postfix/scache[18038]: statistics: domain lookup
hits=110 miss=89 success=55%
Jan  9 19:15:21 postfix postfix/scache[18038]: statistics: address
lookup hits=0 miss=2492 success=0%
Jan  9 19:15:21 postfix postfix/scache[18038]: statistics: max
simultaneous domains=1 addresses=4 connection=4


What means miss=89 success=55%, miss=2492 success=0%?

Thanks
Patrick





Reply | Threaded
Open this post in threaded view
|

Re: Huge active queue and system idle, not delivering

Stan Hoeppner
Patrick Chemla put forth on 1/9/2010 11:17 AM:

> Hi all,
>
> I got these statistics:
>
> Jan  9 19:15:21 postfix postfix/scache[18038]: statistics: start
> interval Jan  9 19:09:03
> Jan  9 19:15:21 postfix postfix/scache[18038]: statistics: domain lookup
> hits=110 miss=89 success=55%
> Jan  9 19:15:21 postfix postfix/scache[18038]: statistics: address
> lookup hits=0 miss=2492 success=0%
> Jan  9 19:15:21 postfix postfix/scache[18038]: statistics: max
> simultaneous domains=1 addresses=4 connection=4
>
>
> What means miss=89 success=55%, miss=2492 success=0%?

http://www.postfix.com/CONNECTION_CACHE_README.html

--
Stan
Reply | Threaded
Open this post in threaded view
|

Re: Huge active queue and system idle, not delivering

Patrick Chemla
Hi Stan,

Thanks for your interest.

Le 09/01/2010 20:21, Stan Hoeppner a écrit :

> Patrick Chemla put forth on 1/9/2010 11:17 AM:
>    
>> Hi all,
>>
>> I got these statistics:
>>
>> Jan  9 19:15:21 postfix postfix/scache[18038]: statistics: start
>> interval Jan  9 19:09:03
>> Jan  9 19:15:21 postfix postfix/scache[18038]: statistics: domain lookup
>> hits=110 miss=89 success=55%
>> Jan  9 19:15:21 postfix postfix/scache[18038]: statistics: address
>> lookup hits=0 miss=2492 success=0%
>> Jan  9 19:15:21 postfix postfix/scache[18038]: statistics: max
>> simultaneous domains=1 addresses=4 connection=4
>>
>>
>> What means miss=89 success=55%, miss=2492 success=0%?
>>      
> http://www.postfix.com/CONNECTION_CACHE_README.html
>
>    
I wen t there but did not find explanations about miss address lookup or
miss domain lookup.
While I have 122,000 messages in active queue I still don't understand
why statistics show max simultaneous domains=1. It should be dozens , or
hundreds.

Patrick

> --
> Stan
>    

Reply | Threaded
Open this post in threaded view
|

Re: Huge active queue and system idle, not delivering

Stan Hoeppner
In reply to this post by Patrick Chemla
Patrick Chemla put forth on 1/9/2010 11:07 AM:

> Hi,
>
> I will try all your advises, but something still very strange for me:
>
> We see that postfix logs show that ehlo process is very slow through
> postfix but very fast by hand. Even I have recorded through
> tcpdump/WireShark and I can see that messages are sent very very very
> quickly in about 1 second.
>
> But still messages are sent at a rate of a dozen in 10 seconds. That
> means that messages are sent 1 by one.
>
> If connexion to qmail servers are slow, or if qmails are mis-parameted,
> too slow or anything else, When I do netstat -apn |grep :25 I get only a
> few connexions from postfix server to qmail servers. Even if DNS+EHLO
> are slow, and more, because DNS+EHLO seem to be slow, why I don't see
> hundreds TCP connexions ESTABLISHED ?

This behavior is likely a result of the connection cache:
http://www.postfix.com/CONNECTION_CACHE_README.html

If one has a large amount of mail destined for a single host, it is inefficient
to open dozens or hundreds of TCP connections and SMTP connections due to the
additional overhead of process/thread count and memory consumption.  It is much
more efficient to pipeline all the mail through a single connection.  One can
only pump so many bits down the wire between two hosts.  If you can fill the
pipe to near capacity with one TCP/SMTP stream, why open 100s of connections to
do the same?  I believe this is why you are not seeing dozens or hundreds of TCP
connections.  Postfix is intelligently designed to avoid this inefficiency.

> I expected that postfix will deliver on 30 qmail servers at the same
> time, and should manage hundreds parallel deliveries, hundreds parallel
> connexions. Is there some parameter or some conception rule that refrain
> him to do so?
>
> I expected that postfix will full up his own CPU/memory creating these
> parallel delivery processes or/and will wait after the qmail servers,
> but on all servers at the same time, on multiple connections to each one.
>
> Am I correct ? or I am dreaming of another mail transport package?
>
> Patrick

As Victor and others have already stated:

1.  In your previous configuration, you had multiple thousands of unique IP
addresses (your customers) connecting directly to your 30 qmail servers to relay
their mail.  qmail performed fine with this configuration because no one qmail
server was seeing thousands of delivery attempts per minute from any one single
IP address.

2.  In your current Postfix configuration, your qmail servers are seeing a
single unique IP address attempting to send multiple thousands of messages per
minute, and qmail is reacting with rate limiting countermeasures because of this.

You need to figure out what settings in the qmail configuration are controlling
this rate throttling and in what way.  Once you find this and change it, you
should see a dramatic improvement in Postfix's ability to quickly move the mail
out of the queue to the 30 qmail servers, most likely using a single or only a
few TCP connections to each qmail server.

--
Stan
Reply | Threaded
Open this post in threaded view
|

Re: Huge active queue and system idle, not delivering

Stan Hoeppner
In reply to this post by Patrick Chemla
Patrick Chemla put forth on 1/9/2010 12:37 PM:

> I wen t there but did not find explanations about miss address lookup or
> miss domain lookup.
> While I have 122,000 messages in active queue I still don't understand
> why statistics show max simultaneous domains=1. It should be dozens , or
> hundreds.

Those are statistics relating to scache performance.  It tells you how many
domains or addresses were able to be delivered via scache reuse.  I.e. how many
emails Postfix was able to send through an already open SMTP connection to a
given host.

Since all of your qmail hosts are configured identically, and should be able to
relay mail bound for any destination on the internet, you should never see
anything less than ~100% in those statistics, _unless_ there is some other kind
of problem.

If your qmail servers are rate limiting via any method, and Postfix is
attempting to send 2000 emails per minute down that one SMTP connection, when
qmail blocks individual deliveries for any reason, those scache failure
statistics will increase.

--
Stan
Reply | Threaded
Open this post in threaded view
|

Re: Huge active queue and system idle, not delivering

Patrick Chemla
Le 09/01/2010 20:54, Stan Hoeppner a écrit :

> Patrick Chemla put forth on 1/9/2010 12:37 PM:
>
>    
>> I wen t there but did not find explanations about miss address lookup or
>> miss domain lookup.
>> While I have 122,000 messages in active queue I still don't understand
>> why statistics show max simultaneous domains=1. It should be dozens , or
>> hundreds.
>>      
> Those are statistics relating to scache performance.  It tells you how many
> domains or addresses were able to be delivered via scache reuse.  I.e. how many
> emails Postfix was able to send through an already open SMTP connection to a
> given host.
>
> Since all of your qmail hosts are configured identically, and should be able to
> relay mail bound for any destination on the internet, you should never see
> anything less than ~100% in those statistics, _unless_ there is some other kind
> of problem.
>
>    

You mean 100% success?
> If your qmail servers are rate limiting via any method, and Postfix is
> attempting to send 2000 emails per minute down that one SMTP connection, when
> qmail blocks individual deliveries for any reason, those scache failure
> statistics will increase.
>
>    
Before I set up the postfix relay to load balance between 30 qmail
servers, each of them was able to accept in his own queue hundreds
thousands email. Email were sent by campaigns of thousands balanced on 3
qmails servers, each one full in CPU/memory working hard to deliver.

Instead of sending each campaign on only 3 qmails, I though that by
sending each campaign on 30 qmails I will cut each one load by ten and
speed up deliveries. But now, postfix is retaining the emails in his own
queue, not pushing the queue down to the qmails.

Postfix server and qmail servers are all about 90%cpu free. only 1 to 9
connexions exist at a time from postfix to qmails.

This is exactly what I would like to append: Instead of a queue of
122,000 on postfix, I expect to have each qmail with a queue of 4000.

Qmails did this before I set up postfix.

Patrick

> --
> Stan
>    

Reply | Threaded
Open this post in threaded view
|

Re: Huge active queue and system idle, not delivering

Stan Hoeppner
Patrick Chemla put forth on 1/9/2010 1:08 PM:

> You mean 100% success?

Yes.

> Before I set up the postfix relay to load balance between 30 qmail
> servers, each of them was able to accept in his own queue hundreds
> thousands email. Email were sent by campaigns of thousands balanced on 3
> qmails servers, each one full in CPU/memory working hard to deliver.
>
> Instead of sending each campaign on only 3 qmails, I though that by
> sending each campaign on 30 qmails I will cut each one load by ten and
> speed up deliveries. But now, postfix is retaining the emails in his own
> queue, not pushing the queue down to the qmails.

An admiral technical goal.  Can you elaborate on these "campaigns"?  You said
previously that you had hundreds of thousands of customers whose email you were
relaying, as if you are an ISP.  Now you are saying the mail load is generated
by "campaigns".  What exactly are these campaigns?

> Postfix server and qmail servers are all about 90%cpu free. only 1 to 9
> connexions exist at a time from postfix to qmails.

This is because the qmail servers won't let the postfix server send any faster.
 We've been over this mulitple times now.  Multiple people have told you the
same thing.  For this to work correctly, you need to figure out why the qmail
servers are rate limiting the postfix server deliveries.

> This is exactly what I would like to append: Instead of a queue of
> 122,000 on postfix, I expect to have each qmail with a queue of 4000.
>
> Qmails did this before I set up postfix.

All MTAs have unique performance characteristics.  You've changed one of the
MTAs in your architecture.  Now you must re-tune your qmail farm servers to work
with the new MTA, postfix, which you have introduced.

This is kinda IT 101 stuff.  You can't automatically assume the problem lies
with the "new thing" you introduced.  Often, the "new thing" exposes problems or
weaknesses that already existed in the old stuff.

--
Stan
Reply | Threaded
Open this post in threaded view
|

Re: Huge active queue and system idle, not delivering

Wietse Venema
In reply to this post by Patrick Chemla
Patrick Chemla:

> Hi all,
>
> I got these statistics:
>
> Jan  9 19:15:21 postfix postfix/scache[18038]: statistics: start
> interval Jan  9 19:09:03
> Jan  9 19:15:21 postfix postfix/scache[18038]: statistics: domain lookup
> hits=110 miss=89 success=55%
> Jan  9 19:15:21 postfix postfix/scache[18038]: statistics: address
> lookup hits=0 miss=2492 success=0%
> Jan  9 19:15:21 postfix postfix/scache[18038]: statistics: max
> simultaneous domains=1 addresses=4 connection=4

Please try the following, as asked half a week ago:

    postconf -e smtp_connection_cache_on_demand=no
    postfix reload

and report if this makes a difference.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Huge active queue and system idle, not delivering

Wietse Venema
Wietse Venema:

> Patrick Chemla:
> > Hi all,
> >
> > I got these statistics:
> >
> > Jan  9 19:15:21 postfix postfix/scache[18038]: statistics: start
> > interval Jan  9 19:09:03
> > Jan  9 19:15:21 postfix postfix/scache[18038]: statistics: domain lookup
> > hits=110 miss=89 success=55%
> > Jan  9 19:15:21 postfix postfix/scache[18038]: statistics: address
> > lookup hits=0 miss=2492 success=0%
> > Jan  9 19:15:21 postfix postfix/scache[18038]: statistics: max
> > simultaneous domains=1 addresses=4 connection=4
>
> Please try the following, as asked half a week ago:
>
>     postconf -e smtp_connection_cache_on_demand=no
>     postfix reload
>
> and report if this makes a difference.

Oh, and please limit the discussion to people who understand the
hard technical internals of Postfix.  Other people please stay out
of the way.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Huge active queue and system idle, not delivering

Patrick Chemla
Wietse,
>> Please try the following, as asked half a week ago:
>>
>>      postconf -e smtp_connection_cache_on_demand=no
>>      postfix reload
>>
>> and report if this makes a difference.
>> Wietse
>>      
I have tested this since yesterday night.

I got some problems with Linux per user number of processes limit. I
fixed it. I also increased some delivery concurrency  figures, and now I
can see up to 1300 processes delivering emails to the qmail servers.

I had a few minutes shot today at a rate of 6300 emails per minute. I
ran a full hour at 180,000 emails per hour. The outbound line was saturated.

CPU is about 30% loaded, no Wait I/O, no swap, memory is large.

I think I will reach about 600,000 emails per hour if I fix some timeout
on the qmails (replace by postfix?). Maybe I could reach 1 million?

The full architecture that I plan will include 2 to 3 clustered postfix
relays and 50 2nd level qmails(or postfix) delivery servers, each with 3
to 5 IP addresses, and upgraded outbound internet connection.

With your help, I better understand now the impact of timeout and
concurrency parameters. In fact, delivery was blocked because postfix
was trying to reuse connections, so was waiting each email to complete
to send the next one. Also, because hundreds processes were created at
start time to manage inbound messages, there were no slots to fork
processes to deliver messages on the other hand. Same problem caused
very slow DNS and EHLO, because no available slots to fork.

Of course, if you want me to post my conf, I will with pleasure.

Many thanks to you, to Victor and Stan.

Patrick

Reply | Threaded
Open this post in threaded view
|

Re: Huge active queue and system idle, not delivering

Stan Hoeppner
Patrick Chemla put forth on 1/10/2010 3:00 PM:

> Wietse,
>>> Please try the following, as asked half a week ago:
>>>
>>>      postconf -e smtp_connection_cache_on_demand=no
>>>      postfix reload
>>>
>>> and report if this makes a difference.
>>>     Wietse
>>>      
> I have tested this since yesterday night.
>
> I got some problems with Linux per user number of processes limit. I
> fixed it. I also increased some delivery concurrency  figures, and now I
> can see up to 1300 processes delivering emails to the qmail servers.
>
> I had a few minutes shot today at a rate of 6300 emails per minute. I
> ran a full hour at 180,000 emails per hour. The outbound line was
> saturated.
>
> CPU is about 30% loaded, no Wait I/O, no swap, memory is large.
>
> I think I will reach about 600,000 emails per hour if I fix some timeout
> on the qmails (replace by postfix?). Maybe I could reach 1 million?
>
> The full architecture that I plan will include 2 to 3 clustered postfix
> relays and 50 2nd level qmails(or postfix) delivery servers, each with 3
> to 5 IP addresses, and upgraded outbound internet connection.
>
> With your help, I better understand now the impact of timeout and
> concurrency parameters. In fact, delivery was blocked because postfix
> was trying to reuse connections, so was waiting each email to complete
> to send the next one. Also, because hundreds processes were created at
> start time to manage inbound messages, there were no slots to fork
> processes to deliver messages on the other hand. Same problem caused
> very slow DNS and EHLO, because no available slots to fork.
>
> Of course, if you want me to post my conf, I will with pleasure.
>
> Many thanks to you, to Victor and Stan.
>
> Patrick

On a technical level I'm happy you got it working.  Just please tell us you're
not sending mass spam with this setup.

--
Stan


Reply | Threaded
Open this post in threaded view
|

Re: Huge active queue and system idle, not delivering

Wietse Venema
In reply to this post by Patrick Chemla
Patrick Chemla:

> Wietse,
> >> Please try the following, as asked half a week ago:
> >>
> >>      postconf -e smtp_connection_cache_on_demand=no
> >>      postfix reload
> >>
> >> and report if this makes a difference.
> >> Wietse
> >>      
> I have tested this since yesterday night.
>
> I got some problems with Linux per user number of processes limit. I
> fixed it. I also increased some delivery concurrency  figures, and now I
> can see up to 1300 processes delivering emails to the qmail servers.
>
> I had a few minutes shot today at a rate of 6300 emails per minute. I
> ran a full hour at 180,000 emails per hour. The outbound line was saturated.
>
> CPU is about 30% loaded, no Wait I/O, no swap, memory is large.
>
> I think I will reach about 600,000 emails per hour if I fix some timeout
> on the qmails (replace by postfix?). Maybe I could reach 1 million?

OK, so you can turn back on that connection caching. Note that
qmail creates and destroys two processes per SMTP session, so
reusing a session is also a win from a CPU resource point of view.

1M/hour, or less than 300/s, should be possible (you mention the
queue is on a solid-state disk). Barring brain damage such as
synchronous syslogging by default on some Linux boxes, borked DNS,
process/file/etc. resource limits, etc.

Perhaps this is a good time to mention that SecurityFocus was
ezmlm->qmail based, and that they switched to Postfix for outbound
deliveries, because qmail simply could not keep up with the volume:

    inbound mail -> qmail -> ezmlm -> multiple postfix MTAs -> internet

That was 2001 when I added QMQP support to Postfix, and this is
still what they appear to be using now, if I must believe their
own Received:  message headers.

Received: from lists2.securityfocus.com (lists2.securityfocus.com [205.206.231.20])
        by outgoing2.securityfocus.com (Postfix) with QMQP
        id 8AC0814370A; Thu,  7 Jan 2010 14:11:35 -0700 (MST)

My very first qmail/Postfix benchmarks showed that qmail was up to
three times slower as a transit MTA, simply because qmail creates
three queue files where Postfix creates one. Creating/deleting
files involves more disk access operations than reading/writing
files, and that hurts especially with small email messages.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Huge active queue and system idle, not delivering

Patrick Chemla
In reply to this post by Stan Hoeppner
Le 10/01/2010 23:58, Stan Hoeppner a écrit :
> On a technical level I'm happy you got it working.  Just please tell us you're
> not sending mass spam with this setup.
>
> --
> Stan
>    

I have to do it for a customer who send as he said, only opt-in mass
emails. He has a big blacklisted email database where he keeps all
unsubscribe messages. He said he has the right filters not to send
unwanted emails.



Thanks
Patrick

Reply | Threaded
Open this post in threaded view
|

Re: Huge active queue and system idle, not delivering

Patrick Chemla
In reply to this post by Wietse Venema
Le 11/01/2010 01:13, Wietse Venema a écrit :

> Patrick Chemla:
>    
>> Wietse,
>>      
>>>> Please try the following, as asked half a week ago:
>>>>
>>>>       postconf -e smtp_connection_cache_on_demand=no
>>>>       postfix reload
>>>>
>>>> and report if this makes a difference.
>>>> Wietse
>>>>
>>>>          
>> I have tested this since yesterday night.
>>
>> I got some problems with Linux per user number of processes limit. I
>> fixed it. I also increased some delivery concurrency  figures, and now I
>> can see up to 1300 processes delivering emails to the qmail servers.
>>
>> I had a few minutes shot today at a rate of 6300 emails per minute. I
>> ran a full hour at 180,000 emails per hour. The outbound line was saturated.
>>
>> CPU is about 30% loaded, no Wait I/O, no swap, memory is large.
>>
>> I think I will reach about 600,000 emails per hour if I fix some timeout
>> on the qmails (replace by postfix?). Maybe I could reach 1 million?
>>      
> OK, so you can turn back on that connection caching. Note that
> qmail creates and destroys two processes per SMTP session, so
> reusing a session is also a win from a CPU resource point of view.
>
>
>
> Wietse
>    
If I do so, will postfix open more than one connexion to each qmail for
parallel deliveries?
I am afraid that if we use connection caching this will create a single
queue on each qmail. As far as I have available resources, I think
prefer parallel deliveries.

Patrick

Reply | Threaded
Open this post in threaded view
|

Re: Huge active queue and system idle, not delivering

Stan Hoeppner
In reply to this post by Patrick Chemla
Patrick Chemla put forth on 1/11/2010 1:02 AM:

> Le 10/01/2010 23:58, Stan Hoeppner a écrit :
>> On a technical level I'm happy you got it working.  Just please tell
>> us you're
>> not sending mass spam with this setup.
>>
>> --
>> Stan
>>    
>
> I have to do it for a customer who send as he said, only opt-in mass
> emails. He has a big blacklisted email database where he keeps all
> unsubscribe messages. He said he has the right filters not to send
> unwanted emails.

Sigh...  This doesn't pass the sniff test.  I fear we've helped enable the
sending of mass UBE.  Patrick would you mind providing the IP netblock(s) you
will be sending these mass mailings from?  Or provide them to me off list
please?  Thanks.

--
Stan
Reply | Threaded
Open this post in threaded view
|

Re: Huge active queue and system idle, not delivering

Patrick Chemla
Le 11/01/2010 09:27, Stan Hoeppner a écrit :

> Patrick Chemla put forth on 1/11/2010 1:02 AM:
>    
>> Le 10/01/2010 23:58, Stan Hoeppner a écrit :
>>      
>>> On a technical level I'm happy you got it working.  Just please tell
>>> us you're
>>> not sending mass spam with this setup.
>>>
>>> --
>>> Stan
>>>
>>>        
>> I have to do it for a customer who send as he said, only opt-in mass
>> emails. He has a big blacklisted email database where he keeps all
>> unsubscribe messages. He said he has the right filters not to send
>> unwanted emails.
>>      
> Sigh...  This doesn't pass the sniff test.  I fear we've helped enable the
> sending of mass UBE.  Patrick would you mind providing the IP netblock(s) you
> will be sending these mass mailings from?  Or provide them to me off list
> please?  Thanks.
>
> --
> Stan
>    
Don't be afraid Stan. They work only on french market, maybe also on
french people who have a mailbox overseas. You have very very very low
chance to be concerned.
Patrick

Reply | Threaded
Open this post in threaded view
|

Re: Huge active queue and system idle, not delivering

Wietse Venema
In reply to this post by Patrick Chemla
Patrick Chemla:
Wietse:
> > OK, so you can turn back on that connection caching. Note that
> > qmail creates and destroys two processes per SMTP session, so
> > reusing a session is also a win from a CPU resource point of view.

Patrick:
> If I do so, will postfix open more than one connexion to each qmail for
> parallel deliveries?

Of course. Connection caching is a performance IMPROVEMENT feature.

However, some qmail implementations are patched and turn on
TARPIT delays when the client sends many messages or recipients
over the same SMTP connection.

        Wietse
12