1

Topic: iRedAdmin-Pro slow loading times and 504 Gateway Timeout (nginx)

==== REQUIRED BASIC INFO OF YOUR IREDMAIL SERVER ====
- iRedMail version (check /etc/iredmail-release): 1.3.2
- Deployed with iRedMail Easy or the downloadable installer? NO
- Linux/BSD distribution name and version: Redhat 7.8
- Store mail accounts in which backend (LDAP/MySQL/PGSQL): MySQL
- Web server (Apache or Nginx): Nginx
- Manage mail accounts with iRedAdmin-Pro? yes
- [IMPORTANT] Related original log or error message is required if you're experiencing an issue.

Whenever I try to login into the admin panel, I usually get a 504 Gateway Timeout error from (nginx), reloading the page usually solves the problem but I still need to wait up to 40 seconds to get into the admin panel.

A fast htop inspection during logon, reveals a high MySQL processor usage during long time periods.

Enabling MySQL slow query I can't find that on logon time, iRedAdmin dashboard page make two queries that cause up to 45 seconds delay to load admin page, this long time periods cause the 504 gateway timeout error:

/usr/sbin/mysqld, Version: 5.7.31-log (MySQL Community Server (GPL)). started with:
Tcp port: 3306  Unix socket: (null)
Time                 Id Command    Argument
# Time: 2021-07-24T00:49:38.728593Z
# User@Host: amavisd[amavisd] @ localhost [127.0.0.1]  Id:    18
# Query_time: 23.753328  Lock_time: 0.000173 Rows_sent: 1  Rows_examined: 2265161
use amavisd;
SET timestamp=1627087778;
-- Get number of outgoing mails.
                              SELECT COUNT(msgs.mail_id) AS total
                              FROM msgs
                              RIGHT JOIN msgrcpt ON (msgs.mail_id = msgrcpt.mail_id)
                              RIGHT JOIN maddr AS sender ON (msgs.sid = sender.id)
                              RIGHT JOIN maddr AS recip ON (msgrcpt.rid = recip.id)
                              WHERE msgs.quar_type <> 'Q'  AND sender.domain IN ('com.my.domain') AND msgs.time_num > UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL 86400 SECOND));


# Time: 2021-07-24T00:50:02.383284Z
# User@Host: amavisd[amavisd] @ localhost [127.0.0.1]  Id:    18
# Query_time: 23.652849  Lock_time: 0.000105 Rows_sent: 10  Rows_examined: 2259143
SET timestamp=1627087802;
-- Get top 10 senders.
                SELECT COUNT(msgs.mail_id) AS total,
                       sender.email_raw AS mail,
                       msgs.policy AS policy
                  FROM msgs
                 RIGHT JOIN maddr AS sender ON (msgs.sid = sender.id)
                 WHERE 1=1  AND sender.domain IN ('com.my.domain') AND msgs.time_num > UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL 86400 SECOND))
                 GROUP BY mail, policy
                 ORDER BY total DESC
                 LIMIT 10;

I verified that the DB cleanup script ran every day (cleanup_amavisd_db.py & cleanup_db.py) with a 7 day data retention period, however I'm still getting over 2 million records inside the msgs table of amavis DB.

After more than 3 years of a nice & fully functional deployment a simple table optimizations solve this particular problem, the command to execute is:


Make sure to ran this MySQL optimization on a maintenance windows, because of locking tables nature of the command. This can in potentially impact your users experience if you run the command on a live production server:


mysql -u root amavisd -e "optimize table maddr, mailaddr, msgrcpt, msgs, outbound_wblist, policy, quarantine, users, wblist;"

In my case the command take up to 4 minutes to accomplish and no one service reboot it's required.

After this simple maintenance, admin panel once again works like a brand new installation!

Hopefully this can help other users, best regards!

====

----

Spider Email Archiver: On-Premises, lightweight email archiving software developed by iRedMail team. Supports Amazon S3 compatible storage and custom branding.

2

Re: iRedAdmin-Pro slow loading times and 504 Gateway Timeout (nginx)

Which iRedAdmin-Pro release are you running? There's a bug in script "tools/cleanup_amavisd_db.py" shipped by iRedAdmin-Pro-SQL-4.7, but it's fixed in iRedAdmin-Pro-SQL-4.8. Could you please upgrade iRedMail and iRedAdmin-Pro to the latest release and try again?

After upgraded to iRedAdmin-Pro-SQL-4.8, no need to run the "optimize table ..." thing.