On a openSUSE Tumbleweed 20210111 test system I evaluate Nextcloud 20. The problem is that even the test system with only one user and only very few files gets ressource problems. Directly after Nextcloud login (with pm.max_children=10) or some minutes later (with pm.max_children=50), PHP-FPM gets stuck. The Nextcloud browser window is open, but idle. I already found, that the number of active PHP-FPM processes is constantly growing. http://localhost/status currently shows 19 active processes: pool: www process manager: dynamic start time: 14/Jan/2021:23:59:47 +0100 start since: 36467 accepted conn: 714 listen queue: 0 max listen queue: 0 listen queue len: 0 idle processes: 1 active processes: 19 total processes: 20 max active processes: 28 max children reached: 0 slow requests: 0 If I close the Nextcloud browser windows, the PHP-FPM active process count is not growing anymore, but it does also not decrease. Nextcloud 18 was running fine on the same test system with identical PHP-FPM configuration. This is my PHP-FPM configuration /etc/php7/fpm/php-fpm.d/www.conf: [www] user = wwwrun group = www listen = localhost:9000 listen = /var/run/php-fpm-www.sock listen.owner = wwwrun listen.group = www listen.mode = 0660 pm = dynamic pm.max_children = 50 pm.start_servers = 2 pm.min_spare_servers = 1 pm.max_spare_servers = 3 pm.status_path = /status ping.path = /ping access.log = /var/log/$pool.access.log catch_workers_output = yes php_flag[display_errors] = on php_admin_value[error_log] = /var/log/fpm-php.www.log php_admin_flag[log_errors] = on php_value[max_execution_time] = 60 I did not found a matching bug report at Nextcloud. Any idea, how I can debug this problem? My main questions are: What are the active PHP-FPM processes doing? Why the active PHP-FPM processes do not get idle after they have done their work? Greetings, Björn
On a openSUSE Tumbleweed 20210111 test system I evaluate Nextcloud 20. The problem is that even the test system with only one user and only very few files gets ressource problems. Directly after Nextcloud login (with pm.max_children=10) or some minutes later (with pm.max_children=50), PHP-FPM gets stuck. The Nextcloud browser window is open, but idle.
I already found, that the number of active PHP-FPM processes is constantly growing. http://localhost/status currently shows 19 active processes:
pool: www process manager: dynamic start time: 14/Jan/2021:23:59:47 +0100 start since: 36467 accepted conn: 714 listen queue: 0 max listen queue: 0 listen queue len: 0 idle processes: 1 active processes: 19 total processes: 20 max active processes: 28 max children reached: 0 slow requests: 0
If I close the Nextcloud browser windows, the PHP-FPM active process count is not growing anymore, but it does also not decrease. I found a solution for this problem. The Apache <Proxy> option "enablereuse=on" causes the high number of "active" PHP-FPM worker
Bjoern Voigt wrote: processes. PHP-FPM does not close them, because Apache reuses the connections. An explaination can be found here: https://httpd.apache.org/docs/2.4/mod/mod_proxy_fcgi.html#examples I changed <Proxy "fcgi://localhost" enablereuse=on flushpackets=auto> </Proxy> to <Proxy "fcgi://localhost" enablereuse=off flushpackets=auto> </Proxy> I still do not understand, why I saw this problem first time with Nextcloud 20. Nextcloud <= 18 was running fine with the same configuration. Greetings, Björn
On Fri, 2021-01-15 at 22:38 +0100, Bjoern Voigt wrote:
Bjoern Voigt wrote:
On a openSUSE Tumbleweed 20210111 test system I evaluate Nextcloud 20. The problem is that even the test system with only one user and only very few files gets ressource problems. Directly after Nextcloud login (with pm.max_children=10) or some minutes later (with pm.max_children=50), PHP-FPM gets stuck. The Nextcloud browser window is open, but idle.
I already found, that the number of active PHP-FPM processes is constantly growing. http://localhost/status currently shows 19 active processes:
pool: www process manager: dynamic start time: 14/Jan/2021:23:59:47 +0100 start since: 36467 accepted conn: 714 listen queue: 0 max listen queue: 0 listen queue len: 0 idle processes: 1 active processes: 19 total processes: 20 max active processes: 28 max children reached: 0 slow requests: 0
If I close the Nextcloud browser windows, the PHP-FPM active process count is not growing anymore, but it does also not decrease.
I found a solution for this problem. The Apache <Proxy> option "enablereuse=on" causes the high number of "active" PHP-FPM worker processes. PHP-FPM does not close them, because Apache reuses the connections. An explaination can be found here: https://httpd.apache.org/docs/2.4/mod/mod_proxy_fcgi.html#examples
I changed <Proxy "fcgi://localhost" enablereuse=on flushpackets=auto> </Proxy> to <Proxy "fcgi://localhost" enablereuse=off flushpackets=auto> </Proxy>
I still do not understand, why I saw this problem first time with Nextcloud 20. Nextcloud <= 18 was running fine with the same configuration.
For what it is worth it - probably not too useful post: I am running Nextcloud 20.0.5 on leap 15.1 for years now (probably started with version 18.x back when I set it up. I have not observed any strange behavior between the version updates - this or anything else over the time <--- I do not set enablereuse - the default is probably off .... My setup is small on public cloud (single core, 2GB RAM + 50GB SSD) running on Apache like you + MariaDb My initial setup was based on Nextcloud documentation/recommendation + some security hardening and resource optimization to fit the small host. I an not an expert, I admit, I learn enough to set it up, audit it - then proceed to forget everything I have learned during the next couple of years - only to repeat it when upgrading/re-installing leap from scratch. I capture the setup (and some knowledge) in Ansible, should I need to redeploy/scale out. Tomas
participants (2)
-
Bjoern Voigt -
TomasK