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

Re: Our postfix works fine, but it is very slow when we send newsletter

Expand Messages
  • Jeroen Geilman
    ... ... how ? Either pickup(8) or smtpd(8) do the queueing; the qmgr only SENDS mail. There could be disk I/O contention, sure, but that would never translate
    Message 1 of 6 , Feb 21, 2013
    View Source
    • 0 Attachment
      On 02/21/2013 03:34 PM, Ralf Hildebrandt wrote:
      > It could be that the process injecting the mails into the queue is
      > stalling the queuemanager, thus sending out can only begin AFTER the
      > injection period.

      ... how ?

      Either pickup(8) or smtpd(8) do the queueing; the qmgr only SENDS mail.
      There could be disk I/O contention, sure, but that would never translate
      into a scenario where no mail could be de-queued before all mail was
      finished queueing.
      These are wholly separate processes after all, and the only point of
      contact is the mail queue, which is concurrent read-write by design.
      By default, there may be many simultaneous processes accessing the queue
      (100 each of smtpd and smtp, for starters.)

      Of course, it could be that he really is sending every single submitted
      message through amavisd and then re-injecting into postfix, thus
      effectively forcing every single message through the pipeline twice.

      This would be inane no matter what kind of IP address it has, but the
      cause of the delays would be the content_filter, nothing else.

      There are settings in amavisd-new that govern what to do when a message
      originates from a trusted or untrusted IP range, offering the option to
      pass it through without scanning.
      If this was impacted by the IP change, that could easily explain the
      delays - but they would still never be sequential.

      Of course, you did ask for logs as well :)

      --
      J.
    Your message has been successfully submitted and would be delivered to recipients shortly.