On Fri, Jun 19, 2015 at 07:58:56AM -0700, E.B. wrote:
> > * 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.
>
> Good tip. This is locally (/usr/sbin/sendmail) submitted
> mail right? Only one of our instances needs to handle that.
Yes, hence the "optional" comment and possibility of disabling
pickup for some/most instances.
> > * 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.
>
> I don't follow last sentence. Dont the smtp(d) processes go
> away when an instance is idle? Given the following I guess
> you just mean that if some are idle it might work nice even
> with one busy instance tuned up for high process concurrency
> but if all instances are like that and become busy, it could
> be a disaster. ?
Don't know about disaster, but my point is that contention for CPU
and network might get rather high if all the instances are at full
throttle, but setting a small static limit for each instance is
generally too tight. This was just touched on in another thread
this week or so.
> So with a few instances expected to become moderately busy
> on moderate hardware, we might be alright. But if we plan
> to have 10-15 domains and IF they all might start to see
> moderate to heavy traffic, the price to pay just for having
> separate "personalities" might be too much?
Something like that, but without the specific numbers.
> Or do people just throw hardware at it when it gets to that
> point?
Or just use a single SMTP server name for all the domains, and no
need for separate certs, ... To scale add more MX hosts that
serve all the domains, and possibly load-balancers, to split
the load for each logical MX host.
> Is it overkill to go 10-20 multiple instances vs. single
> instance with:
>
> - one submission per IP
> - one smtp bound to each IP
You've not yet made a good case for dedicating an instance
per domain, instead of running all the domains on a single
IP with a single certificate, ...
> Isnt the second part there half of the problem you described?
> I mean, if I add a smtp line in master.cf for each IP isnt
> that going to generate same number of smtp processes as with
> multiple instances? You would save on shared smtpd though
> I think. Maybe a middle ground.
I am suggesting you do none of this, but if you must for some
reason, then multiple instances are fine up to a limit. Then
add more network bandwidth and hardware.
> OTOH the only real important point is client-facing SSL to
> match each domain name for submission so the most prudent
> answer is probably single instance with multiple submission ONLY.
Submission is different, here MUAs may well use SNI, but Postfix
does not support that on the server side at this time. Multiple
submission services in master.cf work fine, and are probably
simpler to manage than full-blown multiple instances.
--
Viktor.
