Check this tutorial:
https://docs.iredmail.org/concurrent.processing.html

I wonder:

*) which number do you set in both Postfix and Amavisd.
*) How many (approx) emails did you sent / received every day?

Actually, I just took a look at some server activity graphs and I'd say that the 24 000 estimate is probably on the low side due to the fact that a lot of users may have extended a long weekend and took a couple more days off. I'd put it closer to 30 000.

And keep in mind that when I had my problems a few years ago that number was probably much lower.

You better set a number which matches the RAM you have. If you want to process more emails but you have just 2GB RAM, it's likely Amavisd + ClamAV will stop working due to no enough memory.

So the question is: how much RAM (and CPU) does this server have?

*) Amavisd extracts message to its HOME directory (set in Amavisd config file, parameter $MYHOME), then call SA/ClamAV to scan it. So this directory should be put on SSD for best performance.
*) Obviously, mailboxes should be put on SSD, because this is a mail server, all services are working with the mailboxes.

With 24GB RAM, 8 cores, you can try to increase the numbers to 24, or even higher like 48, 100. Increase once, monitor for few days, if it goes well, increase again. I think set to 50 (and higher) is quite alright with so much RAM.

Easy.

Sometimes it pays to hire a professional (like Zhang) for consultation to solve problems...

30000 mails per day translates to just 20 mails per minute. I don't see why this should be a problem even will less RAM. So again: Easy.

Zhang,

For what it's worth at this point, considering I'm replacing this server, I tried increasing the values in the Amavis and Postfix configuration files first to 24, then to 48, then to 100. Each time, when I re-enabled amavisd, CPU usage immediately tripled (from about 20% to 60%, eventually reaching 80%; see the obvious spike between about 12:30 and 13:30 on the attached graph) and the mail queue immediately started growing from nothing (except a handful of outbound mails being deferred due to greylisting and various similar reasons) to over a hundred inbound and internal emails. After about five minutes when the queue reached over a hundred emails (and growing) I disabled amavisd and the queue took 15-20 minutes to clear. Then I tried raising the numbers in the Amavis and Postfix configuration files another increment. After three tries I gave up and disabled amavisd again, which has been disabled on this server for several years now, almost since the day it was set up.

Simply put, Amavis on this server cannot and does not function, despite having 24 GB of RAM, 8 CPUs and an SSD. I don't get it.

However, that aside, I'd like to revisit two issues that were discussed here previously. These are only issues because in my own experience (as shown above), running on an all-SSD cloud server (Linode), the server could not keep up even with 24 GB of RAM. It does not matter to me if Google runs all of Gmail on a single iRedMail server in Sergey Brin's basement if my own server won't handle 2000 users and 30 000 "easy" emails a day.

1. Above you stated, "Obviously, mailboxes should be put on SSD, because this is a mail server, all services are working with the mailboxes", yet one of the cluster tutorials you link to -- one of only two items in your documentation that seems to refer to processing mail on multiple servers -- talks about putting the mailstore on NFS. (And anyway, why would Amavis be working with static mail boxes at rest that are storing mail that has already been processed?) So my question is, why do you say above that the mailstore should be on a local SSD when that contradicts the aforementioned tutorial on setting up a cluster?

2. And can iRedMail be easily configured to pass email onto a second server rather than storing the email locally? (Obviously iRedAdmin-Pro would need to operate across two servers.) I'm considering doing all of the anti-spam processing on one server and having the mail that gets through forwarded to a storage server.

Thanks again, as always, for your time.

Craig

Thanks for your reply. No. I have had other ideas since this problem first appeared back when I set this server up in late 2013, but atop wasn't one of the tools I used since I hadn't heard of it then. Now, for unrelated reasons, it's simply time to replace this server and move on and waste no more of my time with it.

I guess my case must be so far outside the bell curve, and I just need to hope that the next server won't choke like this one does. If this happened to everyone the forum would be full of complaints and nobody would use iRedMail, so I must be special.

I'd just like Zhang to answer my last two questions so that I can finalise my plans and keep using his software.

*) The iRedAdmin-Pro license covers support for iRedAdmin-Pro itself, not iRedMail server.
*) I appreciate your "coffee", but this is not same as a support ticket.

If you think the answer "Easy" (or whatever) is too simple, feel free to ask me to explain with more details.

It might be a good chance for you to debug Amavisd and get better performance. It sounds like (to me) that your server has some kind of bottleneck. MAYBE slow DNS query, or other part. It will be interesting to figure it out.

Slow DNS will mess up your day. atop will tell you if you're running into a hardware limit.  you'd do well to check both DNS and hardware to find the root of the problem

FWIW, we used to process 20k email's a day on something like penitum-II hardware with 5400rpm IDE disks. the files were smaller but still....

SpamAssassin will check some DNSBL services too (default spamassassin settings), so you'd better double check.

+1

One of the first optimizations I did to iredmail was to add a local DNS cache because I know how terribly systems can perform when DNS is slow.  Yes postfix will perform DNS queries, but postfix does not perform DNSBL lookups on the  domains/URLs in the headers/body of the emails.  Nor does it validate spf/dkim records.    So it would not surprise me that if you had poor/slow DNS resolution times that you would start seeing email backing up. 

I installed unbound myself (despite being a lifelong user of BIND) and the only configuration changes I made to its configuration file was to setup a statistics interval because I wanted to be able to graph usage using munin.  And don't forget to add an entry to /etc/resolv.conf so the system actually uses the local cache - after you've tested that it does actually work - eg. dig +short google.com. @127.0.0.1

For the record, my system is doing ~10K emails a day with 2 cores and 4GB of ram in a public cloud environment and a mix of SSD and spinning disk and I've never run into a case where postfix started queuing up emails.