On Fri, Jun 19, 2015 at 04:52:27AM -0700, E.B. wrote:
> Hi, I appreciate the development of multiple instances
> features thanks you for making it working so easy.
>
> I have a few domains that are light traffic right now,
> low volume mail but in future will become heavily using.
> Theres not a big need to have separate IP address or
> separate Postfix instances for them except needing to
> serve different SSL cert for each domain for the submission
> service so we decided to use different IP address for best
> device compatibility and not try to do SNI in postfix (I think
> I read thats not ready yet)
Plus, most MTAs won't send the SNI extension in the first place,
so even if the server supported it, you'd not get much benefit from
that. Of course most MTAs also don't care what certificate you
present. And finally, it is simplest to just use a single name
for each MX host that handles many domains. Works just fine for
Google, why not for you?
> So we also decided to run separate instances but I know
> we could make one instance doing what we need by making
> a new submission listener in master.cf for each IP address
> and override the SSL cert and key right?
Correct, you don't need separate queues for this perceived need.
> My question is if there is general impact that every new
> Postfix instance has? Assuming that the volume of mail
> would be handled on the same server one way or another,
> what kind of impact does it have to run one postfix instance
> on each IP address? Too many unnecessarily duplicated
> processes running? Is it eating more CPU than necessary?
> How about memory?
The extra costs are:
* One lightweight master(8) process per instance.
This is a tiny fraction of the other costs.
* One pickup(8) daemon that scans a maildir queue
once a minute. This is optional. Just set
authorized_submit_users empty, and comment out
pickup in master.cf.
* A long running queue-manager, this will scan the
incoming and deferred queues periodically and
as new messages arrive. It will also consume
memory (RAM) for scheduling messages in the "active"
queue.
On modern monter multi-CPU large-memory servers, an modest
number of Postfix instances may well outperform a single
instance by giving the multiple queue-managers a larger
combined share of the CPU. Alternatively, one might slice
up servers into virtual machines, each with their own O/S,
but multiple Postfix instances in a single O/S is far more
efficient.
A busy queue-manager often keeps a trivial-rewrite process
busy doing transport table lookups and light-weight address
rewriting. This cost is generally modest. Again, if the
transport table if in LDAP, or SQL database, multiple instances
may outperform here (on machines with enough RAM/CPU/Network),
because when one queue-manager is blocked on transport lookups,
another one gets work done.
* Finally, you end up with a lot more concurrent smtpd(8)
inbound listener processes and smtp(8) outbound delivery
agents. The impact of hundreds of processes competing for
the CPU and network is perhaps negative beyond a certain
point. What you lose with multiple instances is the
ability to scale any one traffic flow to reasonably
high concurrency, while others are "idle", without
paying the cost of peak concurrency for all flows.
So the main concern is what if each instance finds high demand,
and you're running 100s of smtpd/smtp processes for each instance.
There is no global coordination between the various master processes,
to impose a global limit on the number of smtpd(8) processes.
Think of multiple instances as a cheaper than lots of VMs solution.
If the hardware/network/CPU can support N VMs, it can probably
support at least N Postfix instances in a single (possibly bare-metal)
OS. Unless the network is saturated, that "N" may be higher by
some factor of 2 or more for multiple instances over multiple VMs.
--
Viktor.
