UI very slow

Maago

I just installed mailcow on a new server and transferred from a old server with “create_cold_standby” which works perfekt.
However calling the UI on the new machine is very slow. Calling the admin login page takes 5 seconds, showing after login takes 5-6 seconds, every other action like list domains, or list mailboxes takes 5-10 seconds.

Is there any way how to find out the reason for the slow answer of Mailcow? The server overall is fine, other webpages are fast.

DocFraggle

Maago The server overall is fine, other webpages are fast.

So you are running this behind a reverse proxy?

Is this the new it the old mailcow instance?

https://mail.floeser.net/admin/

It’s loading within a few ms for me

esackbauer

Maago other webpages are fast.

I guess something is running on your new server that is responsible for the slowdown.
Hard to tell, could be UFW, other docker versions, and whatnot. If both mailcows are on the same version, I would say something on the new server is not right.
You need to dig deeper into performance analysis. Also have you checked mailcow nginx logs?

esackbauer

LMGTFY:
https://raspberrytips.com/check-linux-performance/

DocFraggle

esackbauer LMGTFY:
7 Simple Linux Commands to See What’s Slowing You Down

👆This, and what are the specs of your new server? Does it meet the minimum requirements?

Maago

DocFraggle
yes, server has 8 vCPU and 16 GB RAM

esackbauer

And also check the logs, of the php-fpm container which hosts the UI and the nginx container and the mysql container.

Maago

esackbauer
mariadb seems ok, no errors, no events.

In php-fpm I see these lines when calling list of mailboxes for example:

php-fpm-mailcow-1 | fc00:6169:6c63:6f77::f - 03/Aug/2025:13:05:26 +0200 “HEAD /forwardinghosts.php” 200
php-fpm-mailcow-1 | fc00:6169:6c63:6f77::f - 03/Aug/2025:13:05:26 +0200 “GET /forwardinghosts.php” 200
php-fpm-mailcow-1 | 172.22.1.10 - 03/Aug/2025:13:05:27 +0200 “GET /json_api.php” 200
php-fpm-mailcow-1 | 172.22.1.10 - 03/Aug/2025:13:05:33 +0200 “HEAD /settings.php” 304

Do I have a issue with IPv4/v6 ?

[unknown]
you can check https://mail.floesernet.de:4443/admin.
This page loads slow …

What I tested is installing a empty mailcow in parallel. This is fast. So something in the config/database is wrong ..
The hostname is another one and I adopted it in mailcow .conf.

Currently I do not use a reverse proxy (is planned later).

[unknown]
you can check https://mail.floesernet.de:4443/admin.
This page loads slow …

What I tested is installing a empty mailcow in parallel. This is fast. So something in the config/database is wrong ..
The hostname is another one and I adopted it in mailcow .conf.

Currently I do not use a reverse proxy (is planned later).

[unknown]
mail.floeser.net is the old instance running behind nginx

esackbauer

And? What about htop, ps aux, free etc?

Maago

esackbauer
htop nearly all zero. 0,01 load. There is nothing alse running on this machine than mailcow (for now).

As I said a empty mailcow instance is fast. After transferring the mailcow from old host it is slow.

Maago

esackbauer
understand. But how is it then explainable why it is running fine on new install, but not on transferred install on same machine?

esackbauer

esackbauer could be UFW, other docker versions, and whatnot. If both mailcows are on the same version, I would say something on the new server is not right.

Or different OS, or different/faulty deployment on hoster side (physical host oversubscribed).

Maago

ufw disabled, both OS Debian 12. I checked other programs on the machine. Running fast and fine.

DocFraggle

This looks more like a timeout issue to me. The requests always take exactly 5s + a few ms, so this seems to be a hard timeout of 5s for something mailcow is trying to reach in the backend maybe.

I suggest you have a look into the logs of all related containers, maybe you find something erroneous which takes 5 seconds

Maago

I found a issue with ldap identity provider .. I will first solve this. Maybe it has something to do with it.

Ok, this solved the issue. The timeout comes from ldap provider. Now it is fast !!
Thanks for your comments and help