Loading ...
Sorry, an error occurred while loading the content.

292432Re: R: Scheduling policies for outgoing smtp server

Expand Messages
  • Stan Hoeppner
    Apr 8, 2013
    • 0 Attachment
      On 4/8/2013 12:31 PM, Wietse Venema wrote:
      > Giorgio Luchi:
      >> I agree with you and with the sentence "Postfix is designed to
      >> work on a mail queue of any size. This is possible because Postfix
      >> works with a fixed memory budget.", and we don't want to break the
      >> architecture.
      ...
      > How does Postfix enforce per-destination concurrency policy, when
      > mail is kept in per-customer queues?
      >
      > What happens when Postfix opens a queue file and discovers that
      > this customer's queue is full? Postfix must not open the same files
      > again and again in an infinite loop, and Postfix must not have
      > "foreach job in the queue" knowledge.
      >
      > We could move such messages to the deferred queue, but that would
      > make queue management more expensive, replacing rename(incoming,
      > active) +remove() with rename(incoming, deferred) +rename(deferred,
      > active) +remove().
      >
      >> I'd like to know if we can engage someone that works on the core
      >> of postfix to implement our feature. We'd like to have this feature
      >> on our servers and so we are also glad to pay for someone that can
      >> agree with us and that could collaborate with us to implement this
      >> request.

      Isn't this a class of problem that can be fairly easily solved using
      virtual machines? Dedicate a VM and Postfix per customer, without
      needing to hack up the MTA. If the issue is "queue fairness" then one
      virtual machine per customer should address this. Disk space is so
      cheap today that dedicating a few GB to a queue for each customer isn't
      a limiting factor. With a sufficiently stripped down custom Linux or
      FreeBSD image the OS memory footprint should be small enough to pack
      many VMs/customers onto one machine. In the case of Linux one may be
      able to use KVM/KSM to consolidate all the like in memory binary images,
      cutting down the total memory footprint even further. The same can be
      done with VMWare ESXi, probably more easily in the latter case, but this
      freebie version probably limits the number of virtual machines to a
      value lower than what you'd need.

      A small farm of eight inexpensive 1U single socket quad core servers
      with 32GB RAM and a couple of 200GB mirrored SSDs could handle quite a
      few customers. Reserve 2GB RAM and 20GB disk for the hypervisor and
      assign 512MB RAM and 3GB disk to each customer VM. This allows for 60
      customer dedicated servers per box each with a ~2.5GB queue. With 8
      such servers that's 480 customer outbound dedicated relay servers in 8U
      of rack space, for relatively little hardware investment. This could be
      tweaked to fit even more customer VMs/queues per box depending on per
      customer queue requirements.

      --
      Stan
    • Show all 17 messages in this topic