Mails stuck in queue until inflow stops

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

Mails stuck in queue until inflow stops

Ramprasad-5
I have a very busy postfix server that acts as a relay. It gets mails
from an application and then forwards the mails to the delivery servers
on local LAN

The application can send mails at rate of  upto 600 mails per second
Postfix has been configured to accept mails all that quickly, but the
delivery is very poor until inflow stops. Only around 20-50 mails per s
Once the app completes the inflow, then the mails are cleared at a rate
of 1000 mails per second

Why ?

Is there a contention on the queue manager when the inflow is too quick ?



Postfix version 3.0.1 on Centos 7.2


postconf -n

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
always_add_missing_headers = yes
bounce_queue_lifetime = 5d
bounce_template_file = /etc/postfix/bounce.cf.default
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
compatibility_level = 2
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
default_destination_concurrency_limit = 500
default_process_limit = 500
disable_mime_input_processing = yes
disable_vrfy_command = yes
hash_queue_depth = 1
hash_queue_names = deferred, defer, hold
header_checks = regexp:/etc/postfix/header_checks
html_directory = no
in_flow_delay = 0s
inet_interfaces = 127.0.0.1
inet_protocols = all
lmtp_destination_concurrency_limit = 30
lmtp_line_length_limit = 9900000
mail_owner = postfix
mailbox_size_limit = 52783082
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
maximal_queue_lifetime = 5d
message_size_limit = 52783082
meta_directory = /etc/postfix
minimal_backoff_time = 30s
mydestination = XXX
myhostname = XXX
mynetworks = /etc/postfix/mynetworks
newaliases_path = /usr/bin/newaliases.postfix
qmgr_message_active_limit = 200000
qmgr_message_recipient_limit = 200000
queue_directory = /dev/shm/postfix
readme_directory = /usr/share/doc/postfix-3.0.1/README_FILES
relayhost = [X]
sample_directory = /usr/share/doc/postfix-3.0.1/samples
setgid_group = postdrop
shlib_directory = /usr/lib64/postfix
smtp_connection_cache_on_demand = yes
smtp_connection_cache_time_limit = 300s
smtp_line_length_limit = 9900000
smtpd_client_connection_count_limit = 0
smtpd_client_connection_rate_limit = 0
smtpd_recipient_limit = 3000
smtpd_recipient_restrictions =  permit_mynetworks,
permit_sasl_authenticated, check_client_access
cidr:/etc/postfix/relay_allowedips, reject
smtpd_restriction_classes = check_env_from
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_local_domain =
smtpd_sasl_security_options = noanonymous
smtpd_sender_login_maps = hash:/etc/postfix/smtpd_sender_login_maps
smtpd_sender_restrictions = permit_mynetworks, check_client_access
cidr:/etc/postfix/permit_sender_ip, reject_sender_login_mismatch, permit
transport_maps =
cdb:/etc/postfix/bounce_transport,cdb:/etc/postfix/suppresslist,hash:/etc/postfix/transport,regexp:/etc/postfix/transport_regex,hash:/etc/postfix/emm_transport
unknown_hostname_reject_code = 550
unknown_local_recipient_reject_code = 550
virtual_alias_maps = hash:/etc/postfix/vmap
virtual_mailbox_base = /var/spool/mail


https://netcore.in/20-years-journey/?utm_source=email-disclaimer&utm_medium=email&utm_campaign=netcore-turns-20

Reply | Threaded
Open this post in threaded view
|

Re: Mails stuck in queue until inflow stops

Wietse Venema
Ram:

> I have a very busy postfix server that acts as a relay. It gets mails
> from an application and then forwards the mails to the delivery servers
> on local LAN
>
> The application can send mails at rate of? upto 600 mails per second
> Postfix has been configured to accept mails all that quickly, but the
> delivery is very poor until inflow stops. Only around 20-50 mails per s
> Once the app completes the inflow, then the mails are cleared at a rate
> of 1000 mails per second
>
> Why ?
>
> Is there a contention on the queue manager when the inflow is too quick ?

No, there is contention for the file system.

If you disabled in_flow_delay, turn it back on, please. This allows
the queue manager to push back, though it works only for clients
that make few parallel connections.

Otherwise, you need a faster disk. SSDs have become quite affordable,
even the 'enterprise' ones that have some extra capacitors to prevent
data corruption after power failure.

        Wietse

Reply | Threaded
Open this post in threaded view
|

Re: Mails stuck in queue until inflow stops

Ramprasad-5


On 04/20/2018 07:14 PM, Wietse Venema wrote:

> Ram:
>> I have a very busy postfix server that acts as a relay. It gets mails
>> from an application and then forwards the mails to the delivery servers
>> on local LAN
>>
>> The application can send mails at rate of? upto 600 mails per second
>> Postfix has been configured to accept mails all that quickly, but the
>> delivery is very poor until inflow stops. Only around 20-50 mails per s
>> Once the app completes the inflow, then the mails are cleared at a rate
>> of 1000 mails per second
>>
>> Why ?
>>
>> Is there a contention on the queue manager when the inflow is too quick ?
> No, there is contention for the file system.
>
> If you disabled in_flow_delay, turn it back on, please. This allows
> the queue manager to push back, though it works only for clients
> that make few parallel connections.
>
> Otherwise, you need a faster disk. SSDs have become quite affordable,
> even the 'enterprise' ones that have some extra capacitors to prevent
> data corruption after power failure.
I am using spool dir on /dev/shm

in flow delay .. slows down smtp connections which the application can
not handle
That is why I have disabled






> Wietse
>


https://netcore.in/20-years-journey/?utm_source=email-disclaimer&utm_medium=email&utm_campaign=netcore-turns-20

Reply | Threaded
Open this post in threaded view
|

Re: Mails stuck in queue until inflow stops

Wietse Venema
Ram:

>
>
> On 04/20/2018 07:14 PM, Wietse Venema wrote:
> > Ram:
> >> I have a very busy postfix server that acts as a relay. It gets mails
> >> from an application and then forwards the mails to the delivery servers
> >> on local LAN
> >>
> >> The application can send mails at rate of? upto 600 mails per second
> >> Postfix has been configured to accept mails all that quickly, but the
> >> delivery is very poor until inflow stops. Only around 20-50 mails per s
> >> Once the app completes the inflow, then the mails are cleared at a rate
> >> of 1000 mails per second
> >>
> >> Why ?
> >>
> >> Is there a contention on the queue manager when the inflow is too quick ?
> > No, there is contention for the file system.
> >
> > If you disabled in_flow_delay, turn it back on, please. This allows
> > the queue manager to push back, though it works only for clients
> > that make few parallel connections.
> >
> > Otherwise, you need a faster disk. SSDs have become quite affordable,
> > even the 'enterprise' ones that have some extra capacitors to prevent
> > data corruption after power failure.
> I am using spool dir on /dev/shm
>
> in flow delay .. slows down smtp connections which the application can
> not handle
> That is why I have disabled

If you can't use the Postfix safety mechanism, then I can't help you.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Mails stuck in queue until inflow stops

Stephen Satchell
In reply to this post by Wietse Venema
On 04/20/2018 06:44 AM, Wietse Venema wrote:
> No, there is contention for the file system.
>
> If you disabled in_flow_delay, turn it back on, please. This allows
> the queue manager to push back, though it works only for clients
> that make few parallel connections.

Looking at master.cf, there is the column "command + args".

Question:  would "nice -n 5 <command>" work?

for example:
   pickup    unix  n       -       n       60      1       nice -5 pickup
   smtp      inet  n       -       n       -       5       nice -5 smtpd
   smtps     inet  n       -       n       -       -       nice -5 smtpd
     -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes
   (submission, too?)

This means that, on disk contention, the other processes have an edge
over the above-listed processes.  As I recall, when you have multiple
processes contending for I/O on a device, the process with the higher
working priority gets selected.  For writes, though, most of the
requests end up being buffered and the writes actually performed by a
daemon or triggered by close(2) or fsync(2).

(All this goes out the window when one moves to solid-state disk.  That
assumes that the system running PostFix can keep up with the inflow; if
not, then my suggestion may still have merit even with SSD.)

In TUNING_README.html, you suggest running a DNS server on the local
machine.  Excellent advice.  When I configured an instance of Postfix as
a smart relay for a double-handful of CPanel/PLESK servers, I found that
a local DNS server with a large DNS cache had a profound positive effect
on clearing out the mail queue in a timely manner.  The computer running
this PostFix instance had eight gigabytes of DRAM, which also let the
Linux file system's cache reduce the accesses to the disk drive.

For high-traffic endpoints (aol.com, gmail.com, yahoo.com, &c) I also
had dedicated senders defined so that I could throttle mail to those
endpoints to prevent triggering anti-spam controls, with the rest going
out the regular way.

Reply | Threaded
Open this post in threaded view
|

Re: Mails stuck in queue until inflow stops

Durga Prasad Malyala
Hi,
We achieved considerable improvement in delivery speed and thereby negligible queues by shifting the mail spool to a faster disk.

Rgds/DP

Sent from my iPhone. Pls excuse brevity and typos if any.

> On 20-Apr-2018, at 8:10 PM, Stephen Satchell <[hidden email]> wrote:
>
>> On 04/20/2018 06:44 AM, Wietse Venema wrote:
>> No, there is contention for the file system.
>> If you disabled in_flow_delay, turn it back on, please. This allows
>> the queue manager to push back, though it works only for clients
>> that make few parallel connections.
>
> Looking at master.cf, there is the column "command + args".
>
> Question:  would "nice -n 5 <command>" work?
>
> for example:
>  pickup    unix  n       -       n       60      1       nice -5 pickup
>  smtp      inet  n       -       n       -       5       nice -5 smtpd
>  smtps     inet  n       -       n       -       -       nice -5 smtpd
>    -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes
>  (submission, too?)
>
> This means that, on disk contention, the other processes have an edge over the above-listed processes.  As I recall, when you have multiple processes contending for I/O on a device, the process with the higher working priority gets selected.  For writes, though, most of the requests end up being buffered and the writes actually performed by a daemon or triggered by close(2) or fsync(2).
>
> (All this goes out the window when one moves to solid-state disk.  That assumes that the system running PostFix can keep up with the inflow; if not, then my suggestion may still have merit even with SSD.)
>
> In TUNING_README.html, you suggest running a DNS server on the local machine.  Excellent advice.  When I configured an instance of Postfix as a smart relay for a double-handful of CPanel/PLESK servers, I found that a local DNS server with a large DNS cache had a profound positive effect on clearing out the mail queue in a timely manner.  The computer running this PostFix instance had eight gigabytes of DRAM, which also let the Linux file system's cache reduce the accesses to the disk drive.
>
> For high-traffic endpoints (aol.com, gmail.com, yahoo.com, &c) I also had dedicated senders defined so that I could throttle mail to those endpoints to prevent triggering anti-spam controls, with the rest going out the regular way.
>
Reply | Threaded
Open this post in threaded view
|

Re: Mails stuck in queue until inflow stops

Viktor Dukhovni
In reply to this post by Ramprasad-5


> On Apr 20, 2018, at 9:12 AM, Ram <[hidden email]> wrote:
>
> I have a very busy postfix server that acts as a relay. It gets mails from an application and then forwards the mails to the delivery servers on local LAN
>
> The application can send mails at rate of  upto 600 mails per second
> Postfix has been configured to accept mails all that quickly, but the delivery is very poor until inflow stops. Only around 20-50 mails per s
> Once the app completes the inflow, then the mails are cleared at a rate of 1000 mails per second

If you can get the application to send to multiple IP addresses, you
could run multiple Postfix instances with multiple queues, each
handling a fraction of the load.  More queue manager processes
might get a larger fraction of the CPU pie.

If the local DNS does round-robin A records, and the application
calls getaddrinfo() for each connection, a multi-homed Postfix
hostname might suffice.

Make sure that your transport table is as fast as possible,
perhaps none at all, or a texthash file.  While the flood
is coming in determine whether the congestion is in the
"incoming" or "active" queue.  I expect the former, but
this needs to be confirmed before considering further
tuning.

--
--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Mails stuck in queue until inflow stops

Bastian Blank-3
In reply to this post by Ramprasad-5
On Fri, Apr 20, 2018 at 06:42:03PM +0530, Ram wrote:
> Is there a contention on the queue manager when the inflow is too quick ?

Well, show some evidence.

> bounce_queue_lifetime = 5d

I thought this is a system that should move mails as fast as possible
outgoing.  Why would it ever handle bounces?

> broken_sasl_auth_clients = yes

Authentication?

> debug_peer_level = 2

Don't use that.

> inet_interfaces = 127.0.0.1

Only listen on localhost.  So you actually have the application and
postfix battling on ressources on this system?  Why?

> lmtp_destination_concurrency_limit = 30

And there you have lmtp.

> lmtp_line_length_limit = 9900000

You can't send such long lines, ever!

> mailbox_size_limit = 52783082

I though this system should send, not retrieve mails?

> mynetworks = /etc/postfix/mynetworks

This does not make sense.

> qmgr_message_active_limit = 200000
> qmgr_message_recipient_limit = 200000

200k messages at the same time?  But also 3k recipient in the same mail?

> smtpd_recipient_restrictions =  permit_mynetworks,
> permit_sasl_authenticated, check_client_access
> cidr:/etc/postfix/relay_allowedips, reject

What?

> transport_maps = cdb:/etc/postfix/bounce_transport,cdb:/etc/postfix/suppresslist,hash:/etc/postfix/transport,regexp:/etc/postfix/transport_regex,hash:/etc/postfix/emm_transport

What are you doing?

Your story does not fit the configuration.  This looks like a generic
purpose relay with authentication, but you told something different.

If your application eats up all the memory, then you won't get any
useful message rate outgoing.

Bastian

--
It is a human characteristic to love little animals, especially if
they're attractive in some way.
                -- McCoy, "The Trouble with Tribbles", stardate 4525.6
Reply | Threaded
Open this post in threaded view
|

Re: Mails stuck in queue until inflow stops

Viktor Dukhovni


> On Apr 20, 2018, at 2:12 PM, Bastian Blank <bastian+postfix-users=[hidden email]> wrote:
>
>> bounce_queue_lifetime = 5d
>
> I thought this is a system that should move mails as fast as possible
> outgoing.  Why would it ever handle bounces?

The application may want to collect bounces for list management.

>> debug_peer_level = 2
>
> Don't use that.

This is in the upstream default main.cf, provided debug_peer_list is empty, it is harmless.

>> inet_interfaces = 127.0.0.1
>
> Only listen on localhost.  So you actually have the application and
> postfix battling on resources on this system?  Why?

If the application sends the *same* message to many users, it would
be dramatically more efficient to send many users in a single envelope,
with VERP if per-user bounces are wanted.
>
>> lmtp_destination_concurrency_limit = 30
>
> And there you have lmtp.

Harmless if unused.

>
>> lmtp_line_length_limit = 9900000
>
> You can't send such long lines, ever!

Ditto.

>> mynetworks = /etc/postfix/mynetworks
>
> This does not make sense.

This is a Debian feature.

>> qmgr_message_active_limit = 200000
>> qmgr_message_recipient_limit = 200000
>
> 200k messages at the same time?  But also 3k recipient in the same mail?

Fine if memory permits.

>> smtpd_recipient_restrictions =  permit_mynetworks,
>> permit_sasl_authenticated, check_client_access
>> cidr:/etc/postfix/relay_allowedips, reject
>
> What?

Looks fine to me, ideally the CIDR table is not too large.

>> transport_maps = cdb:/etc/postfix/bounce_transport,cdb:/etc/postfix/suppresslist,hash:/etc/postfix/transport,regexp:/etc/postfix/transport_regex,hash:/etc/postfix/emm_transport
>
> What are you doing?

Some custom transport rules, regexp transports can be difficult to get right, but if the number of rules is small, and they simple enough this is fine.  That said two CDB tables in a row should really be combined into a single table, and having a "hash" table after that looks silly.  The qmgr(8) will do much less work if there's just one table replacing the first three.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Mails stuck in queue until inflow stops

Stephen Satchell
In reply to this post by Bastian Blank-3
On 04/20/2018 11:12 AM, Bastian Blank wrote:
> If your application eats up all the memory, then you won't get any
> useful message rate outgoing.
>

And worse, if you overflow DRAM, you now add swap load to the disk,
which further slows things down.  One MUST avoid going into swap if
possible, or have an extremely fast backing store (like SSD).

Reply | Threaded
Open this post in threaded view
|

Re: Mails stuck in queue until inflow stops

Ramprasad-5
In reply to this post by Wietse Venema


On 04/20/2018 07:39 PM, Wietse Venema wrote:

> Ram:
>>
>> On 04/20/2018 07:14 PM, Wietse Venema wrote:
>>> Ram:
>>>> I have a very busy postfix server that acts as a relay. It gets mails
>>>> from an application and then forwards the mails to the delivery servers
>>>> on local LAN
>>>>
>>>> The application can send mails at rate of? upto 600 mails per second
>>>> Postfix has been configured to accept mails all that quickly, but the
>>>> delivery is very poor until inflow stops. Only around 20-50 mails per s
>>>> Once the app completes the inflow, then the mails are cleared at a rate
>>>> of 1000 mails per second
>>>>
>>>> Why ?
>>>>
>>>> Is there a contention on the queue manager when the inflow is too quick ?
>>> No, there is contention for the file system.
>>>
>>> If you disabled in_flow_delay, turn it back on, please. This allows
>>> the queue manager to push back, though it works only for clients
>>> that make few parallel connections.
>>>
>>> Otherwise, you need a faster disk. SSDs have become quite affordable,
>>> even the 'enterprise' ones that have some extra capacitors to prevent
>>> data corruption after power failure.
>> I am using spool dir on /dev/shm
>>
>> in flow delay .. slows down smtp connections which the application can
>> not handle
>> That is why I have disabled
> If you can't use the Postfix safety mechanism, then I can't help you.

I know , And in_fllow_delay  works for almost all cases where I use
postfix. Excepting when 1 sec delay per process becomes too much

If I have a high end machine , will running multiple postfix instances
on the same machine help
That way If I change the app to deliver to multiple instances
simultaneously.
There is no IO load running everything in /dev/shm




https://netcore.in/20-years-journey/?utm_source=email-disclaimer&utm_medium=email&utm_campaign=netcore-turns-20

Reply | Threaded
Open this post in threaded view
|

Re: Mails stuck in queue until inflow stops

Ron Wheeler
On 21/04/2018 7:38 AM, Ram wrote:

>
>
> On 04/20/2018 07:39 PM, Wietse Venema wrote:
>> Ram:
>>>
>>> On 04/20/2018 07:14 PM, Wietse Venema wrote:
>>>> Ram:
>>>>> I have a very busy postfix server that acts as a relay. It gets mails
>>>>> from an application and then forwards the mails to the delivery
>>>>> servers
>>>>> on local LAN
>>>>>
>>>>> The application can send mails at rate of? upto 600 mails per second
>>>>> Postfix has been configured to accept mails all that quickly, but the
>>>>> delivery is very poor until inflow stops. Only around 20-50 mails
>>>>> per s
>>>>> Once the app completes the inflow, then the mails are cleared at a
>>>>> rate
>>>>> of 1000 mails per second
>>>>>
>>>>> Why ?
>>>>>
>>>>> Is there a contention on the queue manager when the inflow is too
>>>>> quick ?
>>>> No, there is contention for the file system.
>>>>
>>>> If you disabled in_flow_delay, turn it back on, please. This allows
>>>> the queue manager to push back, though it works only for clients
>>>> that make few parallel connections.
>>>>
>>>> Otherwise, you need a faster disk. SSDs have become quite affordable,
>>>> even the 'enterprise' ones that have some extra capacitors to prevent
>>>> data corruption after power failure.
>>> I am using spool dir on /dev/shm
>>>
>>> in flow delay .. slows down smtp connections which the application can
>>> not handle
>>> That is why I have disabled
>> If you can't use the Postfix safety mechanism, then I can't help you.
>
> I know , And in_fllow_delay  works for almost all cases where I use
> postfix. Excepting when 1 sec delay per process becomes too much
>
> If I have a high end machine , will running multiple postfix instances
> on the same machine help
> That way If I change the app to deliver to multiple instances
> simultaneously.
> There is no IO load running everything in /dev/shm
>
>
>
>
> https://netcore.in/20-years-journey/?utm_source=email-disclaimer&utm_medium=email&utm_campaign=netcore-turns-20 
>
>
>
I hope that you have no spam or virus checking on the inflow.


--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Reply | Threaded
Open this post in threaded view
|

Re: Mails stuck in queue until inflow stops

Ron Wheeler
In reply to this post by Ramprasad-5
On 21/04/2018 8:07 AM, Ram wrote:

>
>
> On 04/21/2018 05:32 PM, Ron Wheeler wrote:
>> On 21/04/2018 7:38 AM, Ram wrote:
>>>
>>>
>>> On 04/20/2018 07:39 PM, Wietse Venema wrote:
>>>> Ram:
>>>>>
>>>>> On 04/20/2018 07:14 PM, Wietse Venema wrote:
>>>>>> Ram:
>>>>>>> I have a very busy postfix server that acts as a relay. It gets
>>>>>>> mails
>>>>>>> from an application and then forwards the mails to the delivery
>>>>>>> servers
>>>>>>> on local LAN
>>>>>>>
>>>>>>> The application can send mails at rate of? upto 600 mails per
>>>>>>> second
>>>>>>> Postfix has been configured to accept mails all that quickly,
>>>>>>> but the
>>>>>>> delivery is very poor until inflow stops. Only around 20-50
>>>>>>> mails per s
>>>>>>> Once the app completes the inflow, then the mails are cleared at
>>>>>>> a rate
>>>>>>> of 1000 mails per second
>>>>>>>
>>>>>>> Why ?
>>>>>>>
>>>>>>> Is there a contention on the queue manager when the inflow is
>>>>>>> too quick ?
>>>>>> No, there is contention for the file system.
>>>>>>
>>>>>> If you disabled in_flow_delay, turn it back on, please. This allows
>>>>>> the queue manager to push back, though it works only for clients
>>>>>> that make few parallel connections.
>>>>>>
>>>>>> Otherwise, you need a faster disk. SSDs have become quite
>>>>>> affordable,
>>>>>> even the 'enterprise' ones that have some extra capacitors to
>>>>>> prevent
>>>>>> data corruption after power failure.
>>>>> I am using spool dir on /dev/shm
>>>>>
>>>>> in flow delay .. slows down smtp connections which the application
>>>>> can
>>>>> not handle
>>>>> That is why I have disabled
>>>> If you can't use the Postfix safety mechanism, then I can't help you.
>>>
>>> I know , And in_fllow_delay  works for almost all cases where I use
>>> postfix. Excepting when 1 sec delay per process becomes too much
>>>
>>> If I have a high end machine , will running multiple postfix
>>> instances on the same machine help
>>> That way If I change the app to deliver to multiple instances
>>> simultaneously.
>>> There is no IO load running everything in /dev/shm
>>>
>>>
>>>
>>>
>>>
>> If you look at a system monitor output (top on Linux is enough), is
>> Postfix using 100% of the CPU? Is there a significant amount of
>> process time in wait queues? Is there lots of spare physical memory?
>>
>> Probably a silly question but are you sure that the sending
>> application or network is not the bottleneck?
>>
>> If you configure Postfix to throw away the e-mails immediately in
>> receipt does the inflow meet your expectations.
> I thought so too.
> I tried using postfix-sink and the mails are sent at max speed. So the
> network is not a problem
>
>
>
> https://netcore.in/20-years-journey/?utm_source=email-disclaimer&utm_medium=email&utm_campaign=netcore-turns-20 
>
>
>
Does the analysis of which postfix tasks are eating the CPU give any hints?

Ron

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Reply | Threaded
Open this post in threaded view
|

Re: Mails stuck in queue until inflow stops

Stephen Satchell
In reply to this post by Ramprasad-5
On 04/21/2018 04:38 AM, Ram wrote:
> There is no IO load running everything in /dev/shm

You can verify your claim by running vmstat(8), such as in:

   vmstat 20 20

(20 times for 20 seconds each time)

You might be surprised how much file system activity there is, even when
you put all of PostFix's files in /dev/shm.  For example, are all of
PostFix's binaries in /dev/shm?  How about the modules loaded by PostFix?