Pourquoi Nextcloud paraît lent, et ce qui le corrige vraiment

Quand une instance Nextcloud paraît poussive, le premier instinct est de lui donner plus de CPU et de mémoire. En général cela ne change rien, parce que le temps part ailleurs : des tâches de fond qui s'exécutent au mauvais endroit, un cache non configuré, des verrous de fichiers qui frappent la base de données, une table à laquelle il manque un index. Voici l'ordre dans lequel nous vérifions, avec les réglages qui corrigent chaque point. Tout ici s'applique que Nextcloud tourne sur un serveur nu ou en conteneurs.

Commencez par ce que Nextcloud vous dit déjà

Nextcloud embarque ses propres vérifications de santé. Lancez-les avant de changer quoi que ce soit :

sudo -u apache php occ setupchecks
sudo -u apache php occ status

Utilisez l'utilisateur du serveur web (apache, www-data ou nginx, selon votre système). Les mêmes résultats apparaissent dans Paramètres d'administration, Vue d'ensemble. Chaque avertissement y est une vraie trouvaille. Corrigez-les d'abord ; plusieurs des points ci-dessous apparaîtront dans cette liste.

Les tâches de fond ne doivent pas voyager sur les chargements de page

Nextcloud a de l'entretien à faire : analyses de fichiers, aperçus, notifications, nettoyage, expiration de l'activité. Par défaut, en mode AJAX, il exécute une tâche chaque fois qu'un utilisateur charge une page. Les utilisateurs paient l'entretien avec leurs propres chargements de page, et sur une instance calme les tâches prennent du retard.

Passez au cron système :

sudo -u apache php occ background:cron

Puis exécutez cron.php toutes les cinq minutes. Un timer systemd est plus propre qu'une entrée crontab parce qu'il journalise les échecs :

# /etc/systemd/system/nextcloud-cron.service
[Service]
Type=oneshot
User=apache
ExecStart=/usr/bin/php -f /var/www/nextcloud/cron.php

# /etc/systemd/system/nextcloud-cron.timer
[Timer]
OnBootSec=5min
OnUnitActiveSec=5min
[Install]
WantedBy=timers.target

Activez-le avec systemctl enable --now nextcloud-cron.timer. Pendant que vous y êtes, définissez une fenêtre de maintenance pour que les tâches lourdes s'exécutent la nuit :

sudo -u apache php occ config:system:set maintenance_window_start --type=integer --value=1

La valeur est une heure en UTC ; les tâches lourdes s'exécuteront dans les quatre heures qui suivent.

Cache et verrouillage des fichiers

Sans cache mémoire, Nextcloud demande encore et encore les mêmes choses à la base de données. Sans backend de verrouillage adapté, chaque opération sur un fichier prend aussi un verrou dans la base. Configurez les deux dans config.php :

'memcache.local' => '\OC\Memcache\APCu',
'memcache.distributed' => '\OC\Memcache\Redis',
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => [
  'host' => '/run/redis/redis.sock',
  'port' => 0,
],

APCu est le cache local rapide à l'intérieur de chaque processus PHP. Redis détient l'état partagé et les verrous de fichiers. Utilisez un socket Unix si Redis est sur la même machine, et assurez-vous que l'utilisateur du serveur web peut l'ouvrir.

APCu doit aussi être activé pour la ligne de commande, sinon occ se plaindra :

; /etc/php.d/40-apcu.ini
apc.enable_cli=1

PHP lui-même : OPcache et le pool FPM

Nextcloud est une grande application PHP. Sans assez d'OPcache, PHP en recompile des parties à chaque requête. Valeurs de départ typiques :

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=32
opcache.max_accelerated_files=20000
opcache.revalidate_freq=60

setupchecks vous dira si le tampon des chaînes internées est trop petit. Puis dimensionnez le pool PHP-FPM à la mémoire que vous avez réellement : pm.max_children multiplié par la mémoire typique d'un worker PHP doit tenir en RAM avec de la place pour la base de données et Redis. Mesurez la mémoire réelle d'un worker sous charge avant de choisir, plutôt que de copier un chiffre d'un forum.

La base de données : index et grands entiers

Les mises à niveau ajoutent parfois des index et des colonnes que les installations existantes ne reçoivent pas automatiquement, parce que les créer sur une grande table prend du temps. Nextcloud vous laisse cette étape :

sudo -u apache php occ db:add-missing-indices
sudo -u apache php occ db:add-missing-columns
sudo -u apache php occ db:add-missing-primary-keys
sudo -u apache php occ db:convert-filecache-bigint

Lancez-les après chaque mise à niveau majeure, dans une fenêtre de maintenance, parce qu'ils peuvent verrouiller de grandes tables. Un index manquant sur la table du cache de fichiers est l'une des raisons les plus courantes pour lesquelles une grande instance paraît lente à la navigation dans les dossiers.

Aperçus : générez-les à l'avance

Les vignettes sont générées la première fois que quelqu'un ouvre un dossier. Un dossier de photos en haute résolution signifie une première visite lente pour celui qui y arrive en premier. Deux choses aident. Limitez la taille des aperçus :

sudo -u apache php occ config:system:set preview_max_x --value=2048 --type=integer
sudo -u apache php occ config:system:set preview_max_y --value=2048 --type=integer

Et, si vos utilisateurs stockent beaucoup d'images, utilisez l'application Preview Generator pour créer les aperçus dans la tâche de fond plutôt qu'à la demande.

L'éditeur bureautique est une charge à part entière

L'édition dans le navigateur avec Collabora tourne comme un service séparé. Nextcloud lui envoie le document, et Collabora le rend et l'édite. Quand les gens disent « Nextcloud est lent » pendant l'édition, le goulet d'étranglement est généralement Collabora, pas Nextcloud. Surveillez son CPU et sa mémoire séparément, pendant que plusieurs personnes éditent de grandes feuilles de calcul en même temps, et dimensionnez-le à partir de ces mesures.

Deux points de configuration comptent à la fois pour la vitesse et pour la sécurité. Pointez Nextcloud vers Collabora par un chemin rapide et proche. Et restreignez les serveurs autorisés à parler à l'interface WOPI de Collabora :

sudo -u apache php occ config:app:set richdocuments wopi_allowlist --value="10.0.0.0/24"

Utilisez-y la plage d'adresses de votre propre serveur Nextcloud, pour que seul votre Nextcloud puisse ouvrir des documents à travers votre éditeur.

Épinglez ce qui tourne

Si vous exécutez Nextcloud en conteneurs, épinglez chaque image (Nextcloud, base de données, Redis, Collabora) à un tag que vous avez choisi.

L'ordre, en bref

• occ setupchecks et corriger chaque avertissement.
• Cron système via un timer, plus une fenêtre de maintenance.
• APCu en local, Redis pour le verrouillage et le cache partagé.
• OPcache correctement dimensionné et un pool FPM dimensionné à partir de mesures.
• Index, colonnes et clés manquants ajoutés après chaque mise à niveau.
• Aperçus limités et générés en arrière-plan.
• Collabora mesuré et dimensionné comme son propre service, avec une liste d'autorisation WOPI.
• Chaque composant épinglé à une version que vous avez choisie.

Ce n'est qu'après tout cela qu'ajouter du matériel vous apprend quelque chose d'utile. Nous exploitons Nextcloud avec Collabora de cette façon pour nos clients sur des instances dédiées, et nous regarderons volontiers la vôtre.

Parler à un ingénieur

Related (rows[1])

Voir aussi : Documents bureautiques infogérés sur Nextcloud · Archive de messagerie privée avec recherche IA locale