mailserver slow occasionally

You system load is at an incredibly high value (19.47), you might want to install the tool "atop" and use it to check which process is using so many resources. It will show resources (CPU, RAM, disk I/O, network and so on) in red that are overloaded. Order the list of processes accordingly to see which one uses the most resources.

Based on that result we can further look for solutions.

Okay, so load is going down, you might need to catch this "in the act" with atop to see which process is causing this.

Might also help to check the logs in /var/log to see if there's anything out of the ordinary at the time when the issue started.

We're sorry for the rude comments posted here, please feel free to continue posting about the issues you're having with your server, we're happy to help :-)

Another thing you may wish to try, in addition to running atop (or top), is to see how many emails are in your mail queue. You can do that by running this command:

mailq | tail -1

Okay, so it looks your high system load is caused by disk I/O overload. The screenshot shows a rather low read and write rate though, so this should not overload the disk. Of course since this is only a snapshot, you might want to watch the DSK lines in atop closely when the problem occurs.

Is this a physical disk, or a virtual system, or some kind of RAID or LVM or so? You might want to check the disk, maybe it has a hardware issue. You might want to test the disk throughput and see if that triggers the problem.

Please sort the process list in atop by disk usage using shift-D.

You can simulate intense disk activity using these:

dd if=/dev/zero of=/tmp/BIGFILE bs=1M count=10000
dd if=/tmp/bigfile of=/dev/null bs=1M count=10000

That will write 10 GB zeroes to /tmp/BIGFILE and read them to null. Open a second shell and watch atop when doing that.

Read and write rate is rather low for a modern HDD, under VMware it should be over 100 MB/s. Are you the operator of the host system?

If not, you might want to ask them if this low R/W rate is normal, or if they have some resource restrictions in place, or if there's any after-effect of that power failure and array rebuild.

This can have a number of reasons though, without further information about the host system and without witnessing the process myself it's hard to guess. It'd be important to watch the system while the issue is occurring, and see the behavior of disk I/O and which processes cause it over a longer time.

If you run top instead of atop you should see what is eating up your IO on the very first line.. the default for top is to sort by CPU usage which should catch the program thats hogging IO

Okay, this might not t really help you, but I'd strongly suggest using a different virtualization software. VMware Server 2 is discontinued and has not been updated in at least 5 years, and even before that, it was recommended by VMware to be only used for testing and development, and not in production use.

Using VMware Server 2 on top of a full-blown Windows server with software RAID can quite likely lead to the problems you're seeing.

If at all possible, I'd suggest migrating to the free ESXi, and possibly use a hardware RAID controller (because ESXi does not support software RAID). Alternatively you can set up software RAID within your virtual machines. While you're at it, you can take a look at the SMART values of your HDDs and perform a long SMART self-test.

Another alternative might be HyperV under Windows Server 2k12, if you for some reason are forced to use a Windows server as the host system. You need a quite powerful machine for that though.

I'm quite sure your performance issues will go away then.

My personal opinion is: Except the host HAS to do other functions like Active Directory, you should use a bare-metal hypervisor like ESXi for best performance.

Your cron jobs should not be the reason for the issues, those run only at specific times. You can repeat the "dd" test a few times to check if the disk throughput is so low all the time.

In your atop screenshot, crond has 54% disk usage, but that's only a relative value. It uses 54% of the total disk I/O, because no other process is using more.

It's striking though, again, that the rather low usage of about 1 MB/s causes a disk load of 34%.

So it's not a specific problem of cron jobs, but a general problem that even low disk I/O causes a high load. It just so happened that cron at that point caused that I/O.

You could check if the virtual disk file has a high level of fragmentation or something like that.

I'm sorry, but otherwise I don't really have any other ideas besides recommending ESXi for production purposes instead of VMware Server 2. I'm not familiar with Server 2 (last time I used it for experiments was about 6 years ago), and this is too complex a setup to successfully guess via the forum. :)