Getting timeouts | VPS too slow?

prostream · January 1, 2021, 4:30pm

Hi together! First of all: My Mail in a box has been running flawlessly for years. It manages about 50 domains with about 120 mailboxes.

For some time now I always get a time-out “Something went wrong, sorry” after logging into the web interface. I get the same time-out when calling the “External DNS” page.

But running sudo ./status_checks.py works fine. I noticed that the CPU of my VPS goes up to 100% when calling the status page from the web interface. So I guess that it just can’t be built fast enough.

Does anyone have experience with this?

Hardware VPS:
2Ghz KVM Shared CPU
8GB RAM
400GB SSD

Edit1: After adding a custom DNS entry i get:

After a reload I see that the entry was created though.

CPU Usage while adding custom DNS:

alento · January 2, 2021, 8:42pm

Hi,

If you time things you will see that the status page times out in exactly 30 (I think) seconds.

The issue is not memory or cpu but rather the timeout setting in nginx. You could increase the setting, but it will be overwritten whenever MiaB updates.

pm74 · January 6, 2021, 3:16am

Could it be a PHP timeout, and if you change the PHP settings, will it also get overwitten?

pm74 · January 6, 2021, 3:19am

Maybe try to resize your box to one that has more CPU than RAM for the same price and use some swap file to give it a bit more memory.

alento · January 6, 2021, 3:58am

It is definitely a nginx setting, and it definitely will be overwritten. Perhaps a issue could be raised on GitHub to increase the time out. Whether or not it is a PHP related time out setting in nginx, I am not certain.

daveteu · January 6, 2021, 5:40am

The python script running the /status page is not PHP and not affected by PHP timeout, Nginx default timeout for proxy to the python script should be 60 seconds.

I checked the ngnix config and it’s not set so it should be using the default timing.

The script runs a couple of tests, and one of them is to run all the dns checks + spam list check, which could be the source of the problem when too many domains exist.

Since MIAB is not designed to be a name server first package, probably try off-loading the domains to a service provider like D/O or Linode? It’s free.

alento · January 6, 2021, 5:45am

Thank you for clarifying that the time out is 60 seconds rather than 30. I had indicated that I wasn’t sure of the exact timeout.

But regardless, the script is taking longer to run, that the time out which is what causes this issue.

prostream · January 6, 2021, 9:26am

I tried to increase NGINX timeout which only just makes it to take longer to load the status page. It also ends up with the same error. Whether it loads successfully or not seems to be absolutely random.

@pm74 I´ll try to contact my hoster to upgrade my VPS and see what will happen.

pm74 · January 6, 2021, 3:12pm

Maybe try to increase the PHP session timeout. PHP can timeout if it has too much to work to do.

alento · January 8, 2021, 1:46am

@prostream

You know, I indicated that the problem is likely the nginx timeout, but I had not considered the php session timeout as @pm74 mentions.

You are using your MiaB to manage considerably more domains than I was so it is quite possible that if the two settings are different, then I never would have ran into the problem with the php session timeout that you are facing. Sorry for not considering it as well.

prostream · January 8, 2021, 7:53am

Yes understood that. I just checked it and there seem to be two php.ini’s:

/etc/php/7.2/cli/php.ini
/etc/php/7.2/fpm/php.ini

In which one do I have to change this?

daveteu · January 8, 2021, 11:43am

if you are talking about your admin panel, it’s not PHP. It’s ran by mailinabox/management/daemon.py .

There won’t be any use changing your php time out, which is used for your nextcloud and roundcube.

maybe try running mailinabox again?

also make sure you update all your packages, i realise there is a slower loading whenever there are new packages that needs to be installed.

To upgrade all packages

sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade

prostream · February 11, 2021, 10:21am

So now i tried all of it and upgraded to the latest version (v0.52). I´m getting more and more timeouts on my web-panel from Mail in a box…

My clients sometimes report a memory error when logging into roundcube. I think it’s time for a stronger server?

daveteu · February 11, 2021, 10:35am

if you have a lot of users using webmail, yes…

Edit: what @fspoettel said sounds reasonably true as well.

fspoettel · February 11, 2021, 11:36am

I saw the same roundcube error directly after the upgrade. For me, this was caused by the restart/update corrupting the login session and went away after logging out of roundcube and logging in again. It didn’t seem to be a hardware issue in my case (might be a different problem though?)

prostream · February 11, 2021, 12:06pm

@fspoettel that´s a nice hint. I think that is plausibel, thanks

prostream · April 11, 2021, 9:13pm

I still have timeouts on almost all status pages in the web interface. But everything works fine so far.

I think this is due to the high number of domains (about 55) and mailboxes (135) that I manage on MIAB… Is MIAB not designed for this scale? Does anyone have a solution to speed up the web interface?

openletter · April 11, 2021, 9:42pm

If you can’t find anything in the logs and your issue remains unresolved here in the forums, I would encourage you to create an issue on GitHub.

Likely not related, but Dovecot sets a limit of active IMAP connections to 250 per CPU thread, which even if you aren’t at the limit now you may want to at least be aware of it.

github.com

mail-in-a-box/mailinabox/blob/90d63fd208ebeca9378a31d97f844363296d6f51/setup/mail-dovecot.sh#L36


echo "Installing Dovecot (IMAP server)..."
apt_install \
	dovecot-core dovecot-imapd dovecot-pop3d dovecot-lmtpd dovecot-sqlite sqlite3 \
	dovecot-sieve dovecot-managesieved

# The `dovecot-imapd`, `dovecot-pop3d`, and `dovecot-lmtpd` packages automatically
# enable IMAP, POP and LMTP protocols.

# Set basic daemon options.

# The `default_process_limit` is 100, which constrains the total number
# of active IMAP connections (at, say, 5 open connections per user that
# would be 20 users). Set it to 250 times the number of cores this
# machine has, so on a two-core machine that's 500 processes/100 users).
# The `default_vsz_limit` is the maximum amount of virtual memory that
# can be allocated. It should be set *reasonably high* to avoid allocation
# issues with larger mailboxes. We're setting it to 1/3 of the total
# available memory (physical mem + swap) to be sure.
# See here for discussion:
# - https://www.dovecot.org/list/dovecot/2012-August/137569.html
# - https://www.dovecot.org/list/dovecot/2011-December/132455.html

alento · April 11, 2021, 11:11pm

Exactly! Nginx has a 60 second timeout set. Running status checks etc for that number of domains takes much longer. So the page will time out / throw an error. You can do everything from the command line and avoid the web status checks, or upgrade to a commercial email service. Let me know if you need any recommendations, or assistance.

openletter · April 11, 2021, 11:44pm

I did not know that.

@prostream Please create an issue at the MiaB GitHub: