postfix maximum load capacities by official document

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
si5
Reply | Threaded
Open this post in threaded view
|

postfix maximum load capacities by official document

si5
Hi

I posted one query similar to the above but I didn't got any satisfactory
replies. The link for the query is provided below:-
http://postfix.1071664.n5.nabble.com/benchmark-for-postfix-td95966.html

We want to find an official document for postfix which will tell the maximum
load capacities for postfix mail server. We tried to search for it but we
could only find performance test research papers.

Actually we have made few changes in postfix source code and we are doing
performance testing on it . But we want to get an official document where
postfix maximum capacities are checked after development so that we can do
an analogous testing and then documentation.

We tried to search for other mail servers also like Microsoft Exchange
server, IBM lotus domino, etc in this regard with no very relevant results.

We really need guidance on this issue. Please any help will really
appreciated.


Regards

Saahil



--
Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
Reply | Threaded
Open this post in threaded view
|

Re: postfix maximum load capacities by official document

Wietse Venema
si5:
> Hi
>
> I posted one query similar to the above but I didn't got any satisfactory
> replies. The link for the query is provided below:-
> http://postfix.1071664.n5.nabble.com/benchmark-for-postfix-td95966.html
>
> We want to find an official document for postfix which will tell the maximum
> load capacities for postfix mail server. We tried to search for it but we
> could only find performance test research papers.

If you can predict the behavior of every program including the
kernel and firmware in your HDD or SSD, then a precise prediction
may be possible given controlled inputs. Otherwise, only estimates
can be made.

> Actually we have made few changes in postfix source code and we are doing
> performance testing on it . But we want to get an official document where
> postfix maximum capacities are checked after development so that we can do
> an analogous testing and then documentation.
>
> We tried to search for other mail servers also like Microsoft Exchange
> server, IBM lotus domino, etc in this regard with no very relevant results.

May I suggest: you test the modified code and the unmodified code
and then try to explain why one is better than the other.

        Wietse

> We really need guidance on this issue. Please any help will really
> appreciated.
>
>
> Regards
>
> Saahil
>
>
>
> --
> Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
>
si5
Reply | Threaded
Open this post in threaded view
|

Re: postfix maximum load capacities by official document

si5
Wietse:

>>si5:
> Hi
>
> I posted one query similar to the above but I didn't got any satisfactory
> replies. The link for the query is provided below:-
> http://postfix.1071664.n5.nabble.com/benchmark-for-postfix-td95966.html
>
> We want to find an official document for postfix which will tell the
> maximum
> load capacities for postfix mail server. We tried to search for it but we
> could only find performance test research papers.

>>If you can predict the behavior of every program including the
>>kernel and firmware in your HDD or SSD, then a precise prediction
>>may be possible given controlled inputs. Otherwise, only estimates
>>can be made.

Thanks for taking to reply.

Yeah, it is correct. But actually we don't want a precise prediction. We
just want like ---> after the development of any server, some maximum load
statistics must be made. And we want to make an analogous statistics for our
case.

> Actually we have made few changes in postfix source code and we are doing
> performance testing on it . But we want to get an official document where
> postfix maximum capacities are checked after development so that we can do
> an analogous testing and then documentation.
>
> We tried to search for other mail servers also like Microsoft Exchange
> server, IBM lotus domino, etc in this regard with no very relevant
> results.

>>May I suggest: you test the modified code and the unmodified code
>>and then try to explain why one is better than the other.

>>        Wietse

Yes we have tested unmodified code with spirent(200,000 mails per 10
minutes) and drops were very less. Ofcourse the unmodified code is better
but we modified it based on our requirements and now we are testing it too.
And it is showing significant mail drops. Once we are able make the drops
less we want to document the maximum load capacities of this modified
server. Thatswhy we are trying to find a document which has such information
so that we can do an analogous testing and documentation.
 
Saahil

> We really need guidance on this issue. Please any help will really
> appreciated.
>
>
> Regards
>
> Saahil



--
Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
Reply | Threaded
Open this post in threaded view
|

Re: postfix maximum load capacities by official document

Bill Cole-3
In reply to this post by si5
On 27 Apr 2018, at 2:50, si5 wrote:

> We want to find an official document for postfix which will tell the
> maximum
> load capacities for postfix mail server. We tried to search for it but
> we
> could only find performance test research papers.
>
> Actually we have made few changes in postfix source code and we are
> doing
> performance testing on it . But we want to get an official document
> where
> postfix maximum capacities are checked after development so that we
> can do
> an analogous testing and then documentation.
>
> We tried to search for other mail servers also like Microsoft Exchange
> server, IBM lotus domino, etc in this regard with no very relevant
> results.

There is a single reason for the lack of any "official" capacity
assertions for any MTA: no such metric can be operationally useful. The
SPECmail benchmark series was never useful for anything other than
generating a minor revenue stream for SPEC and giving salesfolk
meaningless numbers to throw at non-technical customers. It is good that
it was retired.

To compare the performance of the canonical Postfix code to a modified
version, you need to first define what performance metrics you care
about and what sort of mail load you want to test against. You cannot
compare your own test measurements to a baseline performance measurement
for the canonical Postfix code from tests done by someone else with a
test load you can't replicate on a platform you can't replicate. You
need to generate your own controls.

Reply | Threaded
Open this post in threaded view
|

Re: postfix maximum load capacities by official document

Viktor Dukhovni
In reply to this post by si5


> On Apr 27, 2018, at 7:48 AM, si5 <[hidden email]> wrote:
>
> Yeah, it is correct. But actually we don't want a precise prediction. We
> just want like ---> after the development of any server, some maximum load
> statistics must be made. And we want to make an analogous statistics for our
> case.

There is no common-case and so no expected throughput numbers can be
published.

  * What filesystem are using?
  * What transport and rewrite tables?
  * How fast is your DNS?
  * What is the lookup latency for the domains you're sending to?
  * What is your network bandwidth to the destination?
  * What is your IP reputation?
  ...

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: postfix maximum load capacities by official document

Wietse Venema
In reply to this post by si5
si5:
> >>May I suggest: you test the modified code and the unmodified code
> >>and then try to explain why one is better than the other.
>
> >>        Wietse
>
> Yes we have tested unmodified code with spirent(200,000 mails per 10
> minutes) and drops were very less.

That's 300/s, a performance level that Viktor reported for unmodified
Postfix with a Dell server from 2003.

https://groups.google.com/forum/?fromgroups=#!topic/mailing.postfix.users/pPcRJFJmdeA

    "One single Postfix instance has been clocked at ~300 message
    deliveries/second[8] across the Internet, running on commodity
    hardware (a vintage-2003 Dell 1850 system with battery-backed
    MegaRAID controller and two SCSI disks). This delivery rate is
    an order of magnitude below the "intrinsic" limit of 2500 message
    deliveries/second[8] that was achieved with the mail queue on
    a RAM disk while delivering to the "discard" transport (with a
    dual-core Opteron system in 2007)."

> Ofcourse the unmodified code is better
> but we modified it based on our requirements and now we are testing it too.
> And it is showing significant mail drops. Once we are able make the drops
> less we want to document the maximum load capacities of this modified
> server. Thatswhy we are trying to find a document which has such information
> so that we can do an analogous testing and documentation.

There is no 'formula' to predict the behavior of a non-trivial
program, especially not when the performance is determined by remote
network performance, remore DNS server performance, and remote SMTP
server performance. Meaningful numbers require meaningful measurements.

BTW I would not consider a mail system as 'working' until all 'lost
mail' instances can be explained. Your requirements may vary.

        Wietse
si5
Reply | Threaded
Open this post in threaded view
|

Re: postfix maximum load capacities by official document

si5
In reply to this post by Bill Cole-3
On 27 Apr 2018, at 2:50, si5 wrote:

> We want to find an official document for postfix which will tell the
> maximum
> load capacities for postfix mail server. We tried to search for it but
> we
> could only find performance test research papers.
>
> Actually we have made few changes in postfix source code and we are
> doing
> performance testing on it . But we want to get an official document
> where
> postfix maximum capacities are checked after development so that we
> can do
> an analogous testing and then documentation.
>
> We tried to search for other mail servers also like Microsoft Exchange
> server, IBM lotus domino, etc in this regard with no very relevant
> results.

>There is a single reason for the lack of any "official" capacity
>assertions for any MTA: no such metric can be operationally useful. The
>SPECmail benchmark series was never useful for anything other than
>generating a minor revenue stream for SPEC and giving salesfolk
>meaningless numbers to throw at non-technical customers. It is good that
>it was retired.

Really thanks for taking time to reply.

so presently in mail server testing benchmarks are not that important, we
have to take into account our own relevant parameters?

>To compare the performance of the canonical Postfix code to a modified
>version, you need to first define what performance metrics you care
>about and what sort of mail load you want to test against.

Okay. So this means we can consider the areas of postfix source code where
we have have worked on like queue management, etc ?. And we can include the
general performance metrics like --> number of emails attempted in a given
time, number of emails delivered in the given time, etc.?

>You cannot compare your own test measurements to a baseline performance
measurement
>for the canonical Postfix code from tests done by someone else with a
>test load you can't replicate on a platform you can't replicate. You
>need to generate your own controls.
 
Okay. Quite clear.






--
Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
si5
Reply | Threaded
Open this post in threaded view
|

Re: postfix maximum load capacities by official document

si5
In reply to this post by Viktor Dukhovni

> On Apr 27, 2018, at 7:48 AM, si5 &lt;response2saahil@&gt; wrote:
>
> Yeah, it is correct. But actually we don't want a precise prediction. We
> just want like ---> after the development of any server, some maximum load
> statistics must be made. And we want to make an analogous statistics for
> our
> case.

>There is no common-case and so no expected throughput numbers can be
>published.

>  * What filesystem are using?
>  * What transport and rewrite tables?
>  * How fast is your DNS?
>  * What is the lookup latency for the domains you're sending to?
>  * What is your network bandwidth to the destination?
>  * What is your IP reputation?
 
Thanks for replying.

I have numbers for only some parameters above. But i got the basic point
now.




--
Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
si5
Reply | Threaded
Open this post in threaded view
|

Re: postfix maximum load capacities by official document

si5
In reply to this post by Wietse Venema
Wietse Venema wrote

> si5:
>> >>May I suggest: you test the modified code and the unmodified code
>> >>and then try to explain why one is better than the other.
>>
>> >>        Wietse
>>
>> Yes we have tested unmodified code with spirent(200,000 mails per 10
>> minutes) and drops were very less.
>
> That's 300/s, a performance level that Viktor reported for unmodified
> Postfix with a Dell server from 2003.
>
> https://groups.google.com/forum/?fromgroups=#!topic/mailing.postfix.users/pPcRJFJmdeA
>
>     "One single Postfix instance has been clocked at ~300 message
>     deliveries/second[8] across the Internet, running on commodity
>     hardware (a vintage-2003 Dell 1850 system with battery-backed
>     MegaRAID controller and two SCSI disks). This delivery rate is
>     an order of magnitude below the "intrinsic" limit of 2500 message
>     deliveries/second[8] that was achieved with the mail queue on
>     a RAM disk while delivering to the "discard" transport (with a
>     dual-core Opteron system in 2007)."
>
>> Ofcourse the unmodified code is better
>> but we modified it based on our requirements and now we are testing it
>> too.
>> And it is showing significant mail drops. Once we are able make the drops
>> less we want to document the maximum load capacities of this modified
>> server. Thatswhy we are trying to find a document which has such
>> information
>> so that we can do an analogous testing and documentation.
>
> There is no 'formula' to predict the behavior of a non-trivial
> program, especially not when the performance is determined by remote
> network performance, remore DNS server performance, and remote SMTP
> server performance. Meaningful numbers require meaningful measurements.
>
> BTW I would not consider a mail system as 'working' until all 'lost
> mail' instances can be explained. Your requirements may vary.
>
> Wietse


Thankyou for taking time to reply. The information are really helpful.

Regards



--
Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
Reply | Threaded
Open this post in threaded view
|

RE: postfix maximum load capacities by official document

Fazzina, Angelo
Hi, I don't mean to hi-jack this thread but figured this was related.

I was asked in 2014 what rate of mail could flow through per hour.
I gave this response. Do you see anything dangerous in my assumptions ?

Thank you for looking.  BTW Postfix version is likely 2.6

###########

I took a stab at this..
Assumptions:
Deliver 20,000 emails
All to Yahoo
Each email goes to only ONE recipient
Talima sends us no more than 1000 emails at once
Talisma does not send email to us faster than we can send email out

1000 emails in per second = 20 seconds
20 emails out per second per domain (yahoo) = 996 seconds

996 + 20 = 1016 seconds = 16.93 minutes for 20,000 emails
60 minutes / 16.93 minutes = 3.54
20,000 emails * 3.54 = 70880 emails per hour

GOTCHAS:
A. If Talisma sends to us FASTER than we send mail out, there is a ONE second delay added when
We accept a new message.

B. Our queues only hold 20,000 emails at a time

Obviously they will not send to only one DOMAIN but this should be easy to re-calculate once they know
How many different domains a campaign is going to..

QUESTIONS:
Can domains we send to handle this current setup ?
should we change our setup?  
If we do change setup, will the domains we send to be able to handle our higher volume ?
############


-ANGELO FAZZINA

ITS Service Manager:
Spam and Virus Prevention
Mass Mailing
G Suite/Gmail

[hidden email]
University of Connecticut,  ITS, SSG, Server Systems
860-486-9075

-----Original Message-----
From: [hidden email] <[hidden email]> On Behalf Of si5
Sent: Friday, April 27, 2018 11:40 AM
To: [hidden email]
Subject: Re: postfix maximum load capacities by official document

Wietse Venema wrote

> si5:
>> >>May I suggest: you test the modified code and the unmodified code
>> >>and then try to explain why one is better than the other.
>>
>> >>        Wietse
>>
>> Yes we have tested unmodified code with spirent(200,000 mails per 10
>> minutes) and drops were very less.
>
> That's 300/s, a performance level that Viktor reported for unmodified
> Postfix with a Dell server from 2003.
>
> https://groups.google.com/forum/?fromgroups=#!topic/mailing.postfix.users/pPcRJFJmdeA
>
>     "One single Postfix instance has been clocked at ~300 message
>     deliveries/second[8] across the Internet, running on commodity
>     hardware (a vintage-2003 Dell 1850 system with battery-backed
>     MegaRAID controller and two SCSI disks). This delivery rate is
>     an order of magnitude below the "intrinsic" limit of 2500 message
>     deliveries/second[8] that was achieved with the mail queue on
>     a RAM disk while delivering to the "discard" transport (with a
>     dual-core Opteron system in 2007)."
>
>> Ofcourse the unmodified code is better
>> but we modified it based on our requirements and now we are testing it
>> too.
>> And it is showing significant mail drops. Once we are able make the drops
>> less we want to document the maximum load capacities of this modified
>> server. Thatswhy we are trying to find a document which has such
>> information
>> so that we can do an analogous testing and documentation.
>
> There is no 'formula' to predict the behavior of a non-trivial
> program, especially not when the performance is determined by remote
> network performance, remore DNS server performance, and remote SMTP
> server performance. Meaningful numbers require meaningful measurements.
>
> BTW I would not consider a mail system as 'working' until all 'lost
> mail' instances can be explained. Your requirements may vary.
>
> Wietse


Thankyou for taking time to reply. The information are really helpful.

Regards



--
Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
Reply | Threaded
Open this post in threaded view
|

Re: postfix maximum load capacities by official document

Viktor Dukhovni


> On Apr 30, 2018, at 5:02 PM, Fazzina, Angelo <[hidden email]> wrote:
>
> B. Our queues only hold 20,000 emails at a time

What is the reason for that?  Postfix has no such built-in limit...

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

RE: postfix maximum load capacities by official document

Fazzina, Angelo
Hi again, I guess I don't have a clear understanding of this in the man page ?

Ran command
        [root@mta1 ~]# man 5 postconf




default_recipient_limit (default: 20000)

The default per-transport upper limit on the number of in-memory recipients. These limits take priority over the global qmgr_message_recipient_limit after the message has been assigned to the respective transports. See also default_extra_recipient_limit and qmgr_message_recipient_minimum.

Use transport_recipient_limit to specify a transport-specific override, where transport is the master.cf name of the message delivery transport.




Thanks.

-ANGELO FAZZINA

ITS Service Manager:
Spam and Virus Prevention
Mass Mailing
G Suite/Gmail

[hidden email]
University of Connecticut,  ITS, SSG, Server Systems
860-486-9075

-----Original Message-----
From: [hidden email] <[hidden email]> On Behalf Of Viktor Dukhovni
Sent: Monday, April 30, 2018 6:12 PM
To: Postfix users <[hidden email]>
Subject: Re: postfix maximum load capacities by official document



> On Apr 30, 2018, at 5:02 PM, Fazzina, Angelo <[hidden email]> wrote:
>
> B. Our queues only hold 20,000 emails at a time

What is the reason for that?  Postfix has no such built-in limit...

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: postfix maximum load capacities by official document

Wietse Venema
Fazzina, Angelo:
> Hi again, I guess I don't have a clear understanding of this in the man page ?
>
> Ran command
> [root@mta1 ~]# man 5 postconf
>
> default_recipient_limit (default: 20000)
>
> The default per-transport upper limit on the number of IN-MEMORY
> recipients.

The Postfix mail queue is not an IN-MEMORY queue. That would limit
the amount of email that Postfix can handle, and it would violate
the requirement that mail is not lost after a system crash.

        Wietse
Reply | Threaded
Open this post in threaded view
|

RE: postfix maximum load capacities by official document

Fazzina, Angelo
Hi, okay that makes sense.

I guess my next question is what is going on when we get a bulk mail campaign or spam attack and I see the /var/spool/postfix/incoming
Directory only allow 20,000 files in there ?


Thanks.

-ANGELO FAZZINA

ITS Service Manager:
Spam and Virus Prevention
Mass Mailing
G Suite/Gmail

[hidden email]
University of Connecticut,  ITS, SSG, Server Systems
860-486-9075


-----Original Message-----
From: [hidden email] <[hidden email]> On Behalf Of Wietse Venema
Sent: Tuesday, May 1, 2018 10:27 AM
To: Postfix users <[hidden email]>
Subject: Re: postfix maximum load capacities by official document

Fazzina, Angelo:
> Hi again, I guess I don't have a clear understanding of this in the man page ?
>
> Ran command
> [root@mta1 ~]# man 5 postconf
>
> default_recipient_limit (default: 20000)
>
> The default per-transport upper limit on the number of IN-MEMORY
> recipients.

The Postfix mail queue is not an IN-MEMORY queue. That would limit
the amount of email that Postfix can handle, and it would violate
the requirement that mail is not lost after a system crash.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: postfix maximum load capacities by official document

Wietse Venema
Fazzina, Angelo:
> Hi, okay that makes sense.
>
> I guess my next question is what is going on when we get a bulk
> mail campaign or spam attack and I see the /var/spool/postfix/incoming
> Directory only allow 20,000 files in there ?

20,000 FILES? Where did you get that idea from?

Postfix queues can have millions of files. The maximal queue size
depends on the file system capacity, and on how long it takes to
deliver those messages (if it takes a year then it is no good).

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: postfix maximum load capacities by official document

Viktor Dukhovni
In reply to this post by Fazzina, Angelo


> On May 1, 2018, at 10:38 AM, Fazzina, Angelo <[hidden email]> wrote:
>
> Hi, okay that makes sense.
>
> I guess my next question is what is going on when we get a bulk mail campaign or spam attack and I see the /var/spool/postfix/incoming
> Directory only allow 20,000 files in there ?

It is the "active" queue that qmgr(8) avoids filling with too many messages
at once, because each *active* message requires memory for scheduler metadata.
The incoming queue will grow (almost) as large as the filesystem permits, but
once the queue manager is no longer keeping up some SMTP sessions will incur
the inflow-delay (but this does not prevent input from running faster than
output, rather it keeps the amount by which input *exceeds* output to at most
input concurrency / inflow_delay.

If you allow 100 parallel SMTP sessions, and have a 1s inflow delay, then
the input rate can *exceed* the output rate by 100 msgs/sec.  If that
goes on for long enough, your incoming queue will get rather large, but
only your filesystem space will cap that, not any hard-limit in Postfix.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

RE: postfix maximum load capacities by official document

Fazzina, Angelo
Yes, I was guessing, must have be active and not incoming queue.
Thanks for the explanation of what I was seeing.

Have a good week.

-ANGELO FAZZINA

ITS Service Manager:
Spam and Virus Prevention
Mass Mailing
G Suite/Gmail

[hidden email]
University of Connecticut,  ITS, SSG, Server Systems
860-486-9075


-----Original Message-----
From: [hidden email] <[hidden email]> On Behalf Of Viktor Dukhovni
Sent: Tuesday, May 1, 2018 12:38 PM
To: Postfix users <[hidden email]>
Subject: Re: postfix maximum load capacities by official document



> On May 1, 2018, at 10:38 AM, Fazzina, Angelo <[hidden email]> wrote:
>
> Hi, okay that makes sense.
>
> I guess my next question is what is going on when we get a bulk mail campaign or spam attack and I see the /var/spool/postfix/incoming
> Directory only allow 20,000 files in there ?

It is the "active" queue that qmgr(8) avoids filling with too many messages
at once, because each *active* message requires memory for scheduler metadata.
The incoming queue will grow (almost) as large as the filesystem permits, but
once the queue manager is no longer keeping up some SMTP sessions will incur
the inflow-delay (but this does not prevent input from running faster than
output, rather it keeps the amount by which input *exceeds* output to at most
input concurrency / inflow_delay.

If you allow 100 parallel SMTP sessions, and have a 1s inflow delay, then
the input rate can *exceed* the output rate by 100 msgs/sec.  If that
goes on for long enough, your incoming queue will get rather large, but
only your filesystem space will cap that, not any hard-limit in Postfix.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: postfix maximum load capacities by official document

Viktor Dukhovni


> On May 1, 2018, at 12:50 PM, Fazzina, Angelo <[hidden email]> wrote:
>
> Yes, I was guessing, must have be active and not incoming queue.
> Thanks for the explanation of what I was seeing.

I hope it is clear that the active queue size limits don't determine
the total number of messages Postfix can accept.  Considerably more
mail might be sitting in "incoming" and "deferred".

On modern systems with lots of RAM you can also raise the active
queue limits from the default 20,000 to 100,000 or perhaps more.
Do it gradually and see how much memory qmgr(8) consumes.

More active queue space can help when most of the traffic is to
a small number of slow destinations, which can fill the active
queue and starve out other traffic.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

RE: postfix maximum load capacities by official document

Fazzina, Angelo
Thanks again,
To give you a little insight, I load balance 3 of these for smtp.uconn.edu
So back when I saw the 20K limit it was just DNS round robin which is not real load balancing.

I doubt latency of throughput will be significant enough that I notice it in the future, my experience seeing issues was over 3 years ago.



[root@mta1 incoming]# tune2fs -l /dev/mapper/vg_mta3-lv_root |grep  'Filesystem created'
Filesystem created:       Tue Mar 19 13:58:16 2013

[root@mta1 incoming]# free -m
             total       used       free     shared    buffers     cached
Mem:          1877       1526        350          0        208        747
-/+ buffers/cache:        571       1305
Swap:         2015        193       1822

[root@mta1 incoming]# more /etc/redhat-release
Red Hat Enterprise Linux Server release 6.9 (Santiago)

-ANGELO FAZZINA

ITS Service Manager:
Spam and Virus Prevention
Mass Mailing
G Suite/Gmail

[hidden email]
University of Connecticut,  ITS, SSG, Server Systems
860-486-9075


-----Original Message-----
From: [hidden email] <[hidden email]> On Behalf Of Viktor Dukhovni
Sent: Tuesday, May 1, 2018 1:23 PM
To: Postfix users <[hidden email]>
Subject: Re: postfix maximum load capacities by official document



> On May 1, 2018, at 12:50 PM, Fazzina, Angelo <[hidden email]> wrote:
>
> Yes, I was guessing, must have be active and not incoming queue.
> Thanks for the explanation of what I was seeing.

I hope it is clear that the active queue size limits don't determine
the total number of messages Postfix can accept.  Considerably more
mail might be sitting in "incoming" and "deferred".

On modern systems with lots of RAM you can also raise the active
queue limits from the default 20,000 to 100,000 or perhaps more.
Do it gradually and see how much memory qmgr(8) consumes.

More active queue space can help when most of the traffic is to
a small number of slow destinations, which can fill the active
queue and starve out other traffic.

--
        Viktor.