Slow web GUI

[mag]

Hi,

I have an EFA 4.0.4 server running for about 2 years now however the web interface is getting slower and slower to respond. This includes both the Mailwatch login as well as clicking on any message via the web interface and Recent Messages. Talking about 20+ seconds before anything changes and is displayed.

It is not a very busy server, with 10 - 30 messages being processed daily. There are a total of 3,937 messages (as displayed in the Search and Reports).

The server load average is around 0.10 and there is 8GB of memory with around 3GB free (no swap used), so it does not appear to be a resource issue. Console and other command line actions are fine, as well as transferring messages to the upstream mail server, so just a slow web interface.

How can I troubleshoot or has anyone experienced this before?
Is any maintenance required for Mailwatch or pruning of databases, etc?

Appreciate any thoughts and suggestions.

[shawniverson]

You won't want to keep emails in eFa indefinitely for this reason. You'll want to come up with a reasonable quarantine retention that balances performance.

You can adjust the retention in eFa-Configure under MailWatch Settings.

[mag]

Thanks for that suggestion but I suspect the issue still lies elsewhere.

The retention period was set to 60 days. I have moved it down to 15, with no noticeable change to loading times. I'll give it a day or so to see if this needs to work it's way through.

[henk]

Suggestions on reporting/solving issues can be found here viewtopic.php?t=2974

With just 4K messages and 20 sec Gui response time, it's obvious there are issues.

In order to be able to troubleshoot, check the logs first and show the Mysqltuner output

I would start here:

Code: Select all

/var/log/httpd

is it a physical or virtual server?

[henk]

eFa Current Software versions, for convenience visible on one screen, can save a lot of time solving issues

2024-01-05 17_40_36-MailWatch for MailScanner.jpg (47.28 KiB) Viewed 70513 times

[mag]

Appreciate your responses - I had searched prior to posting and not found any other instances that appeared relevant.
I am also pretty familiar with Linux.

Here is some additional info:
This is a virtual machine running Rocky Linux 8.9 on a Proxmox (8.1.3) server.

I have/had checked all logs under /var/log/http - regular and ssl versions of access and error logs - there are no indications of an issue or any errors in the http/s logs.

Here are the Software versions:

Code: Select all

MailWatch Version: 1.2.18
Postfix Version: 3.5.9
MailScanner Version: 5.5.1
ClamAV Version: 0.103.11
SpamAssassin Version: 3.4.6
PHP Version: 7.2.24
MySQL Version: 10.3.39-MariaDB
GeoIP Database Version: GeoLite2 Country database 2023-12-29 08:04:33

and here is the output from mysqltuner with the nogood and noinfo options. I do not see anything critical in there either, unless I am misreading it

Code: Select all

[root@nospam ~]# mysqltuner.pl --nogood --noinfo
 >>  MySQLTuner 1.7.14 - Major Hayden <major@mhtx.net>
 >>  Bug reports, feature requests, and downloads at http://mysqltuner.com/
 >>  Run with '--help' for additional options and output filtering


-------- Log file Recommendations ------------------------------------------------------------------
[!!] Log file /var/log/mariadb/mariadb.log is empty

-------- Storage Engine Statistics -----------------------------------------------------------------

-------- Analysis Performance Metrics --------------------------------------------------------------

-------- Security Recommendations ------------------------------------------------------------------
[!!] There is no basic password file list!

-------- CVE Security Recommendations --------------------------------------------------------------

-------- Performance Metrics -----------------------------------------------------------------------
[!!] Temporary tables created on disk: 61% (888 on disk / 1K total)
[!!] Table cache hit rate: 12% (122 open / 969 opened)

-------- Performance schema ------------------------------------------------------------------------

-------- ThreadPool Metrics ------------------------------------------------------------------------

-------- MyISAM Metrics ----------------------------------------------------------------------------
[!!] Key buffer used: 18.3% (24M used / 134M cache)
[!!] Read Key buffer hit rate: 74.6% (362 cached / 92 reads)

-------- InnoDB Metrics ----------------------------------------------------------------------------
[!!] InnoDB Write Log efficiency: 41.11% (40995 hits/ 99714 total)

-------- AriaDB Metrics ----------------------------------------------------------------------------
[!!] Aria pagecache hit rate: 80.5% (4K cached / 885 reads)

-------- TokuDB Metrics ----------------------------------------------------------------------------

-------- XtraDB Metrics ----------------------------------------------------------------------------

-------- Galera Metrics ----------------------------------------------------------------------------

-------- Replication Metrics -----------------------------------------------------------------------

-------- Recommendations ---------------------------------------------------------------------------
General recommendations:
    When making adjustments, make tmp_table_size/max_heap_table_size equal
    Reduce your SELECT DISTINCT queries which have no LIMIT clause
    Increase table_open_cache gradually to avoid file descriptor limits
    Read this before increasing table_open_cache over 64: http://bit.ly/1mi7c4C
    Read this before increasing for MariaDB https://mariadb.com/kb/en/library/optimizing-table_open_cache/
    This is MyISAM only table_cache scalability problem, InnoDB not affected.
    See more details here: https://bugs.mysql.com/bug.php?id=49177
    This bug already fixed in MySQL 5.7.9 and newer MySQL versions.
    Beware that open_files_limit (32184) variable
    should be greater than table_open_cache (2000)
    Performance schema should be activated for better diagnostics
    Consider installing Sys schema from https://github.com/mysql/mysql-sys for MySQL
    Consider installing Sys schema from https://github.com/good-dba/mariadb-sys for MariaDB
Variables to adjust:
    tmp_table_size (> 32M)
    max_heap_table_size (> 32M)
    table_open_cache (> 2000)
    performance_schema = ON enable PFS

Any other suggestions?

[henk]

As you mentioned only the Gui is very slow ( with 10 - 30 messages being processed daily)

start monitoring these logfiles and then Login to the Gui and start clicking messages and see what happens if mail comes in.

Code: Select all

tail -F /var/log/httpd/error_log  /var/log/messages /var/log/php-fpm/www-error.log /var/log/maillog

btw, Nr of CPU's > 1?

On Mysql.
make sure there's the correct Mysq version label in

Code: Select all

/etc/my.cnf.d/mariadb-server.cnf

in your case : [mariadb-10.3]

and below this label, to avoid silly dns lookups

Code: Select all

skip-name-resolve

When running mysqltuner, without additional options, also have a look at InnoDB buffer pool / data size.

Depending on the result, you could Run mysqlchecks

Code: Select all

mysqlcheck --all-databases --analyze
mysqlcheck --all-databases --optimize

[mag]

Thanks for all the help and suggestions.

I resolved this issue - the issue turned out to be my web browser (Firefox) and DNS over HTTP settings.
I run my own internal caching DNS server and the internal domain name of the EFA server resolves to a different IP internally vs externally. Once I whitelisted the EFA server name in Firefox, I stopped having the delay.