On 2020-07-12 20:59, Greg Sims wrote:
We are making good progress building a mail server. The server is a
KVM running CentOs 8.2 with vcpus=2 and ram=4GB. The system is under
heavy load and is likely limited by disk performance. The load is
generated by a second KVM using SMTP to send email. Everything seems
to be working except there is nothing in /var/log/maillog for a period
of 3 minutes. I'm not sure what is causing the omission of logs and
how to correct this issue.
Maybe systemd-journald rate limit is your problem. I found some
information here
https://www.rootusers.com/how-to-change-log-rate-limiting-in-linux
Do these 3 minutes show up when you call journalctl -u postfix@-.service
or more specific
journalctl -u postfix@-.service --since="2020-07-12 03:06:00"
--until="2020-07-12 03:11:00"
I'm concerned that we are not following this recommendation, "Don't
overwhelm the disk with mail submissions. Optimize the mail submission
rate by tuning the number of parallel submissions and/or by tuning the
Postfix in_flow_delay parameter setting." There is no indication in
/var/log/maillog of problems (other than 3 minutes of missing logs). I
do not know if "overwhelming the disk" would lead to shutting down
data going to the maillog altogether. I will set in_flow_delay = 2s
for this KVM mail server this evening.
The performance snapshots below seem to show: cpu load average is not
heavy, plenty of ram free, no swapping (stable at 108Mi), dm-0 is
working hard at 129 tps and postfix seems to be keeping up with the
load with 39-50 emails in the queue. This run started at 03:05 and
created two minutes of data in /var/log/maillog -- and then nothing
for 3 minutes starting at 03:07. I am certain the email in the
missing three minutes was actually delivered or I would be seeing lots
of negative feedback from our subscribers.
You can also put
03:07:04 up 17:31, 0 users, load average: 0.42, 0.26, 0.10
total used free shared buff/cache
available
Mem: 3.7Gi 832Mi 2.0Gi 101Mi 931Mi
2.5Gi
Swap: 1.0Gi 108Mi 915Mi
Device tps kB_read/s kB_wrtn/s kB_read
kB_wrtn
dm-0 129.00 0.00 2373.50 0
4747
incoming/active queue:
T 5 10 20 40 80 160 320
640 1280 1280+
TOTAL 39 39 0 0 0 0 0 0
0 0 0
gmail.com [1] 8 8 0 0 0 0 0
0 0 0 0
att.net [2] 7 7 0 0 0 0 0
0 0 0 0
bellsouth.net [3] 7 7 0 0 0 0 0
0 0 0 0
sbcglobal.net [4] 7 7 0 0 0 0 0
0 0 0 0
aol.com [5] 4 4 0 0 0 0 0
0 0 0 0
icloud.com [6] 4 4 0 0 0 0 0
0 0 0 0
yahoo.com [7] 1 1 0 0 0 0 0
0 0 0 0
outlook.com [8] 1 1 0 0 0 0 0
0 0 0 0
deferred queue:
T 5 10 20 40 80 160 320
640 1280 1280+
TOTAL 1 0 0 0 0 0 0 0
0 0 1
icloud.com [6] 1 0 0 0 0 0 0
0 0 0 1
03:07:11 up 17:31, 0 users, load average: 0.36, 0.25, 0.10
total used free shared buff/cache
available
Mem: 3.7Gi 858Mi 1.9Gi 101Mi 933Mi
2.5Gi
Swap: 1.0Gi 108Mi 915Mi
Device tps kB_read/s kB_wrtn/s kB_read
kB_wrtn
dm-0 121.50 0.00 2326.00 0
4652
incoming/active queue:
T 5 10 20 40 80 160 320
640 1280 1280+
TOTAL 56 56 0 0 0 0 0 0
0 0 0
gmail.com [1] 13 13 0 0 0 0 0
0 0 0 0
att.net [2] 11 11 0 0 0 0 0
0 0 0 0
sbcglobal.net [4] 11 11 0 0 0 0 0
0 0 0 0
bellsouth.net [3] 9 9 0 0 0 0 0
0 0 0 0
icloud.com [6] 6 6 0 0 0 0 0
0 0 0 0
yahoo.com [7] 5 5 0 0 0 0 0
0 0 0 0
rocketmail.com [9] 1 1 0 0 0 0 0
0 0 0 0
deferred queue:
T 5 10 20 40 80 160 320
640 1280 1280+
TOTAL 1 0 0 0 0 0 0 0
0 0 1
icloud.com [6] 1 0 0 0 0 0 0
0 0 0 1
Thanks, Greg
Links:
------
[1] http://gmail.com
[2] http://att.net
[3] http://bellsouth.net
[4] http://sbcglobal.net
[5] http://aol.com
[6] http://icloud.com
[7] http://yahoo.com
[8] http://outlook.com
[9] http://rocketmail.com
--
Christian Kivalo
