Web access becomes slow after some time -- explosion of www-data processes number up to 152!

Nextcloud version: 20.0.2
Operating system and version: Debian Linux 10.6
Apache version: 2.4.38
PHP version: 7.4

This is my first install of Nextcloud.

For a first 10-15 min the web pages open quickly (including gallery, maps, files…), but after access becomes very slow (each page opens after 20-70 sec delay).

During this time of dramatic slowdown, the CPU is at 3%-30% usage, physical memory is at 60%-70% usage, swap file is under 10% usage.

I noticed that the number of www-data processes (each about 234 mb) is exploding from normal 14 to 152!

After sending from terminal: killall -u www-data, the situation goes back to fast web responses for some time. This slowdown affects all devices. At the same time Webmin is responsive and fast.

I have 4 users, but currently only 1 (myself) is using it. I use saved session to open Nextcloud from the same browser in several tabs.
I’ve loaded a big collection of photos (20 GB) and enabled syncing from my phone.

One more thing I noticed: one tab that was already in was responsive even when a new tab had huge delays trying to login.

I thought it might be due to me never logging out… but after setting up an experiment, exactly after logout the explosion of processes happened again.

Please let me know what experiment to set up and what logs might be helpful.

Thank you.

I think you hit the same issue like what I am trying to solve in my setup.

From what I understood, the main problem is that the background process to generate the thumbnails of the photos eats a lot of resources. The only suggestion that I know of so far is to use https://apps.nextcloud.com/apps/previewgenerator. But I am still having difficulties to properly use it the way I want to.

The following are some links to the information and the solutions that have been taken by the writers to solve their problems:

  1. https://www.bentasker.co.uk/documentation/linux/671-improving-nextcloud-s-thumbnail-response-time
  2. https://ownyourbits.com/2019/06/29/understanding-and-improving-nextcloud-previews/
1 Like

Thank you for a clue. So I installed the manual thumbnails generator. But how do I limit automatic thumbnail generator to be used only on Gallery open?

Well… I think you are out of luck with that. Sorry… :smiley:

As far as I know, we can only have either ‘enable_previews’ => true or ‘enable_previews’ => false. If we chose the latter and we want to have the tumbnails pre-generated, then we need to install “Preview Generator”, otherwise no thumbnails.

I actually prefer the on-demand thumbnails generator. But it seems that it does not respect the tumbnails that it previously generated, because sometimes it re-generates some thumnails even there is no update on the original photos. And the worse that I observed is that, it automatically generates the thumbnails of all photos that are being uploaded, instead of generating them when the users access the directory containing the photos for instance.

I’m trying to figure another way. Maybe, just maybe, I could use Linux ability to limit some processes so that other could work faster. On the other hand I can’t even understand why having 14% CPU usage, 67% memory usage, and almost 0% disk load… why oh why my computer can’t serve me my webpage fast enough? Yes, I see 152 www-data processes, but computer isn’t busy that much. Maybe there is a PHP 7.4 glitch that causes it go slow? Maybe it is the Apache problem?
I would like to dig deeper with this glitch. Computer has enough resources, but pages open slow unless I kill 152 and leave only 14 www-data processes.

I’ll keep on looking for a solution. For now I will run the experiment of killing thumbnail auto creation and report what that will do.

Well… New experiment showed that this problem is not caused by Thumbnails auto generation. I disabled all thumbnails in config.php by adding ‘enable_previews’ => false. Restarted Apache2 (with service apache2 restart), killed all www-data, opened the gallery and found no thumbnails…

Yet… in about 5 min I see again 152 processes and the page opens super slow.

Now that thumbnails are not a problem, what else could I do to debug the issue?

From my experience, I found apache is bloated. That is why since years ago I moved to lighttpd and then to nginx to have more resource effective web server.

If you still want to use apache, as far as I remember you can limit the number of child process of apache to limit the resource usage. But of course with the impact that the access to your Nextcloud will be slower.

You can also limit the number of php-fpm processes by changing the pm.max_children on your /fpm/pool.d/www.conf

Edited: add info about php-fpm

If you changed the config.php, restarting apache is not enough. You have to restart your php (are you using php-fpm?) as well.

Yes, I am using php-fpm. Sincerely I feel like a noob. In my life the only lite experience I’ve had with webservers previously was Joomla. I don’t really know much about which component does what. So, for example I don’t know what php-fpm does and if I could do without it and what impact it will have. I thought killing all processes belonging to www-data and restarting apache2 will restart everything related to the server.
What is the command to restart PHP? (in debian)

I am using Devuan as I don’t like the idea of systemd. So for me to start php-fpm is using command /etc/init.d/php7.3-fpm restart. I don’t know (and I don’t really want to know) how to do that in systemd based system. :smiley:

1 Like

Does anyone know how I could debug this and try to catch what’s slowing down apache2?

Well, turns out you can debug it (a little) straight in your browser (who knew?). So here is a screenshot of the requests and server responses:

This is if I click “Files” in the top menu. Where do I go from here?

A very strange thing happened:
I’ve edited /etc/apache2/mods-available/mpm_prefork.conf
and changed MaxRequestWorkers from 150 to 250.

AND

Now it seams to be working fast for a much longer period of time (so far no slowdowns) and I always see about 14 www-data processes. Strange. It looks like it was a few allowed processes short. But I’ll continue to watch this…