Hi Wietse, I limited my postfix installation to default_process_limit 5, 4, 3, 2, and even 1, and still saw the same effects. I am thinking it might be either my opendkim milter (which applies the DKIM signature for each mail) or SASL as these are the only other processes on the server. Are you aware of any issues with either related to I/O? I have not seen any configuration settings for opendkim to do any performance throttling.
I am still dumbfounded how this continues to occur. I am not sending mail in large quantity - maybe 7,000-8,000 total - just in a short amount of time. The I/O shouldn't be THAT high... at least not to leave the server unresponsive... the mail client connects to my server every evening (around midnight) and sends mails in a burst fashion within an hour or so. I did as you suggested and opened a console on the VMWare host, did a tail of the mail log, and it sent mail for a good 5-10 minutes before finally becoming unresponsive. I tried to Ctrl-C out of tail, nothing. I've done the same monitoring with top and still see no culprit for the sudden halt. I check syslog and other logs on the server and see no crashes or panics. Any other ideas what might be causing this? Further debugging I can do? Thanks On Fri, Jan 19, 2018 at 2:26 PM, Wietse Venema <wie...@porcupine.org> wrote: > Zach Sheppard: > > Wietse: > > > > I have not made any changes to rsyslog.conf. All it does it redirect all > > mail log messages to one log in /var/log/mail which I rotate with a cron > > script nightly. However, I do agree that it really could be the only > other > > process that could be hanging the server. > > > > I'm not able to determine what program is consuming the CPU because I > can't > > login to the console when this occurs. The only way I can recover the > > machine is by forcibly powering off. > > I suspect that heavy I/O from Postfix and syslog is too much for > your VM. > > To diagnose the problem, run screen(1) on a stable machine, and > then open a login session into the VM while it still responsive. > Then come back to that screen session when things go bad. You're > likely to find that when the VM is very slow, all time is spent in > the VM's kernel, and the host's VMM. > > Note that VMs, while fine for CPU-bound jobs, can introduce serious > CPU overhead for things that do massive amounts of I/O like Postfix > plus syslog. > > If you can't get a better VM, you can reduce the impact from a > 'large' mailing by reducing the number of concurrent Postfix SMTP > server and client processes. > > # postconf default_process_limit=10 > # postfix reload > > Wietse > -- This message may contain confidential information and is intended only for the individuals named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
