This symptom can occur for a number of reasons. My guess is that PHP processes that your webmail uses, got stuck. To find out more about it, we'll first need to know which PHP and interface webmail is using. The default configuration is located in
/usr/local/psa/admin/conf/templates/default/webmail/roundcube.php
But maybe you have a custom configuration in
/usr/local/psa/admin/conf/templates/custom/webmail/roundcube.php
Which one is correct?
In that file you will find a line similar or equal to
FcgidInitialEnv PP_CUSTOM_PHP_CGI_INDEX [B]plesk-php74-fastcgi[/B]
with the last parameter indicating the PHP version and interface. Which is the one you are using?
See details on options here:
https://support.plesk.com/hc/en-us/...e-PHP-version-for-webmail-in-Plesk-for-Linux-
If you are using FastCGI, then it is possible that all FastCGI processing slots are "full" by PHP processes so that no new connect can be made. This would result in an unresponsive webmail page. You could check this situation by running
ps aux | grep roundcube
and simply checking if there are "many" such processes related to roundcube. "many" is relative. Maybe you can check how your Apache web server is configured, to find out, what it will accept as the maximum number of concurrent FCGI requests. This information is stored in /etc/httpd/conf.d/fcgid.conf, for example:
Code:
FcgidMaxProcesses 100
FcgidMaxProcessesPerClass 10
Maybe you want to increase these values a little? Let's say FcgidMaxProcesses to 500 and FcgidMaxProcessesPerClass to 40? You can tell from the number of concurrent webmail processes you see if this could help. If you change the fcgid.conf settings, restart Apache afterwards
systemctl restart apache2
.
Another approach could be to change the handler from Fastcgi to FPM. How to do that can be derived from the above mentioned KB article.