Shore Up
A constricted channel opening wider as queued geometric forms flow through
iRedMail ServerPostfix

Increase iRedMail Performance to process more emails

Ketan Aagja3 min read
No ratings yet

How to increase iRedMail performance to process more emails? This is the question that has been harassing many iRedMail administrators.

I had been playing with iRedMail performance since 5+ years now. And still not thinking to discontinue it. If you haven’t tried your hands on this powerful mammoth of Email server, give it a try here: iRedMail Site. Start testing it and see how simple it is to install, configure and go live.

Creator and core developer of iRedMail (ZhangHuangbin) also has created beautiful, neat and easy to understand help documents. Following documents you can configure almost everything. iRedMail Document Site

I run my iRedMail performance server on following specs. This is far better or I would say excellent in terms of sending and receiving emails.  There is also another same specs server running as backup server which is replicated from primary server.

  • Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz
  • 20 GB DDR3 RAM
  • 3 TB HDD with RAID 5
  • CentOS Linux release 7.2.1511 (Core) - Minimal Install

Following is the list to check out on which I have applied various performance settings:

  • Applied on iRedMail server - 0.9.5-1
  • Current users on server - 850
  • Current emails processing speed - 10,000+ per minute

Here you can follow these instructions to increase iRedMail performance.

Do not apply these settings directly on your production server. First understand each and every effects of these settings. If want to check, just apply it on any test server before going live.

First step is very simple, just setting up more concurrent Amavisd-new content filter processes. Default process limit is 2.

You can verify default process limit by hitting following command:

[root@mail ~]# cat /etc/amavisd/amavisd.conf | grep $max-servers
#$max_servers = 2; # num of pre-forked children (2..30 is common), 
# Do not notify administrator about SPAM/VIRUS from remote servers.
$max_servers = 2;

Let’s change default value to some higher. In my case I have applied 15 processes utilizing more CPU and RAM resources of my server which gives me best email processing performance.

Changing default value in amavisd also require change in postfix master.cf file having same value which you specify in amavisd.conf file.

Commands:

vi /etc/amavisd/amavisd.conf

Change following to your desired value:

# Num of pre-forked children.
# WARNING: it must match (equal to or larger than) the number set in
# /etc/postfix/master.cf "maxproc" column for the 'smtp-amavis' service.
$max_servers = 15;

Now change postfix master file to the same value:

vi /etc/postfix/master.cf

Change following value:

# Amavisd integration.
smtp-amavis unix - - n - 15 smtp

Once you complete above changes you must have to restart both amavisd and postfix services so that new changes takes effect.

 systemctl amavisd restart

systemctl postfix restart

All Done now…!!! Just start sending some emails and measure the performance. You can fine tune iRedMail performance with above changes as per email processing of your iRedMail server.

Written by
Ketan Aagja

Runs enterprise networks and security for a living, and writes Shore Up to turn two decades of hands-on Linux, Windows and mail-server work into guides you can actually use.

More about the author →

Was this article helpful?

Tap a star — no sign-in needed.

Be the first to rate this article.

Related guides

LinuxMail

Detect Mail Loops by Parsing Postfix Logs

A mail loop is a message that never lands: a misconfigured relay that points back at itself, two autoresponders bouncing the same notice back and forth, or a forward that feeds an address into its own alias. Postfix leaves clear fingerprints for this in its log, and a small parser turns those fingerprints into a report you can read in the morning.

8 min read
LinuxMailSecurity

Catch SMTP Brute-Force on Port 587 with Fail2ban

Password-guessing against the submission port (587) is constant background noise on any internet-facing mail server. Each attempt shows up in your mail log as a SASL authentication failure, and the standard, boring, reliable way to act on a pattern of them is Fail2ban: it tails the log, counts failures per source IP, bans the IP in your firewall, and can email you when it does. This guide wires that up for the submission service specifically.

8 min read
MailLinux

Bulk-Export Postfix Virtual Maps to an Encrypted Backup

This guide builds a small bash script that reads your Postfix virtual-table configuration, copies the source files behind each file-based map ( hash: , lmdb: , btree: , cdb: , texthash: ) plus main.cf and master.cf , bundles them into a tarball, and encrypts that tarball with GnuPG so you can store it off-box safely. The purpose is a routine, restorable snapshot of your mail routing and alias data.

9 min read
MailLinux

One Report Correlating Mail Service Errors and Delivery Failures

This is a read-only reporting script . It queries the systemd journal and prints a single, time-ordered report that interleaves two things: systemd service-level errors for your mail stack (Postfix and Dovecot logging at priority err or worse) and Postfix delivery failures (bounces, deferrals, and NOQUEUE rejects). The point is to see, in one place, whether a run of deferred deliveries at 02:15 lines up with Dovecot restarting at 02:14.

10 min read