Increase iRedMail Performance to process more emails
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.50GHz20 GB DDR3 RAM3 TB HDD with RAID 5CentOS 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-1Current users on server - 850Current 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.confChange 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.cfChange 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 restartAll 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.
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
Automate Failover Testing Between Primary and Secondary Mail Servers
Having two MX hosts is not the same as knowing failover works. The only way to trust it is to test it: confirm both hosts answer on port 25 and accept mail for your domain, and once in a while prove that when the primary is down, the secondary still takes the message and holds it. This guide gives you a small probe script you can run on a schedule, and a controlled live drill for the real thing.
Audit Postfix for Open Relay Vulnerabilities with Bash
This script reads your Postfix relay-control settings with postconf and flags configurations that could let outsiders relay mail through your server — the classic "open relay" that gets you onto blocklists and turns your box into a spam cannon. It is read-only. It changes nothing, writes nothing, and reloads nothing , so there is no config to back up and nothing to roll back. It simply reports.
Per-Domain Mail Volume Trends from Postfix Logs
This guide gives you a small Python 3 script that reads Postfix's delivery log lines, extracts the recipient domain and the delivery status ( sent , bounced , deferred , etc.) from each line, and prints a per-domain, per-day count as CSV so you can spot volume trends. It is read-only : it opens log files, counts lines, and writes nothing back to the system. It does not touch Postfix, the queue, or the logs themselves.
Automate Postfix Transport Map Updates Without Downtime
This guide gives you a small bash script that rebuilds a Postfix transport map from its flat-file source, validates the configuration, and reloads Postfix so the new routing takes effect. postfix reload re-reads configuration and recycles daemons gracefully — it does not drop in-flight SMTP connections or stop the queue, which is why we use it instead of restart .