Single user Cloud - bad performance

Hello everyone,

I’m using Nextcloud for five months and I’m really happy about the functionalities.
It’s somehow overkill because i installed it only for me, so it can be regarded as a single-use Cloud.

Unfortunately the system is very slow, and it is even slower since upgrade to Nextcloud 17 (from 16).

I have an idea about your recommendations, but because I’m the only one using the Cloud, I installed it on my Gandi M instance which doesn’t exactly match them:

512MB memory
2 CPU
4 PHP processes
32 Max MySQL

Under Nextcloud 16, the worst was already with ‘Password’ application taking lots of time to load, and to answer search.
Since Nextcloud 17, even the default ‘Files’ application is a pain.

Nextcloud is often reaching the maximum PHP children limits:

[10-Dec-2019 06:47:00] WARNING: [pool www] server reached max_children setting (4), consider raising it

And the maximum memory of 512MB is reached often (225000 times since last reboot on 6th December 2019 …).

I disabled the most of applications I do NOT use, and I’ve just disabled file locking since I’m alone to use my Cloud.
What could I do to get it smoothy ?

Configuration :

Nextcloud version _17.0.1_
Operating system and version _Gandi Linux 4.9.124-paas-2270098_
Apache _2.4.35_
PHP version _7.3.6_

The issue you are facing:

Is this the first time you’ve seen this error? (Y/N): N

Steps to replicate it:

  1. Open any pages of my Nextcloud
  2. Use either Passwords of Files applications
  3. very very slow (between 5 and 40+ seconds to fully load pages)

The output of your Nextcloud log in Admin > Logging => https://pastebin.com/CMbFutJt

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):

<?php
$CONFIG = array (
  'instanceid' => 'private',
  'passwordsalt' => 'private',
  'secret' => 'private',
  'trusted_domains' =>
  array (
    0 => 'cloud.private.net',
  ),
  'datadirectory' => '/srv/data/web/vhosts/cloud.private.net/htdocs/data',
  'dbtype' => 'mysql',
  'version' => '17.0.1.1',
  'overwrite.cli.url' => 'http://cloud.private.net',
  'dbname' => 'nextcloud',
  'dbhost' => 'localhost',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'nextcloud',
  'dbpassword' => 'private',
  'installed' => true,
  'mail_smtpmode' => 'smtp',
  'mail_smtphost' => 'mail.gandi.net',
  'mail_sendmailmode' => 'pipe',
  'mail_from_address' => 'cloud',
  'mail_domain' => 'private.net',
  'mail_smtpport' => '465',
  'maintenance' => false,
  'mail_smtpsecure' => 'ssl',
  'mail_smtpauthtype' => 'LOGIN',
  'mail_smtpauth' => 1,
  'mail_smtpname' => 'cloud@private.net',
  'mail_smtppassword' => 'private',
  'updater.release.channel' => 'stable',
  'theme' => '',
  'loglevel' => 2,
  'logtimezone' => 'Europe/Paris',
  'filelocking.enabled' => false,
);

The output of your Apache access log => https://pastebin.com/8yHk3cS0

fpm.log:

[10-Dec-2019 06:47:00] WARNING: [pool www] server reached max_children setting (4), consider raising it

I played around with a raspberry some time ago. When you have little memory, it’s quite challenging to get decent performance. In general, caching works great, however with little RAM, this is difficult. Back then, the raspberry had about 1 gb ram, and you could improve it compared to the default performance but it wasn’t great either. Now you have only 512 MB RAM. With mysqltuner and tuning-primer.sh you can check the database settings, give the database just as much memory it really needs. Sorry, that I can’t give you a hint to a switch to speed it up.

I wouldn’t try too much and rather get a better system.

Thanks for you answer.

I’m not sure it is a database performance issue; it is mainly a PHP process one (limited to 4 parallel php-fpm) => is there any way to change/configure/tune Nextcloud memory and running parallel processus ?

You can either use caching so some stuff don’t need to be executed each time (but it uses memory itself) or you reduce the number of functions and apps. Beyond of that, you need to see which operations take a lot of time and how you can optimize this. Sometimes the logs can give hints or what elements in the interface take the longest being generated.