Le cron.php de nextcloud pompe toutes les ressources

Mon serveur YunoHost

Matériel: BriqueInternet (olimex lime1 avec disque SATA et microSD pour le boot)
Version de YunoHost: 4.1.73
J’ai accès à mon serveur : En SSH | Par la webadmin
Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : oui
Si oui, expliquer: J’ai utilisé nand-sata-install pour migrer le système et les données (tout sauf le /boot) vers le disque SATA.

Description du problème

Brique très lente, mémoire saturée (oui je sais 512Mb + 512Mb de swap c’est peu mais ça fonctionnait pas trop mal avant que je ne réinstalle ma brique et que j’utilise nand-sata-install).

Le diagnostique de base est assez simple, il y a plusieurs tâche cron en parallèle pour /var/www/nextcloud/cron.php et du coup mysql qui pompe toutes les ressources.

Mais … pourquoi … la réponse arrive bientôt.

mysql

Mais que fait Mysql ?

J’ai édité le fichier /etc/mysql/my.cnf pour journaliser les requêtes longues.

…
[mysqld]
…
slow_query_log                  = 1
slow_query_log_file             = /var/log/mysql/slow.log
long_query_time                 = 5
…

Et du coup dans /var/log/mysql/slow.log il y avait des requêtes du genre …

INSERT INTO `oc_filecache` (`mimepart`, `mimetype`, `mtime`, `size`, `etag`, `storage_mtime`, `permissions`, `name`, `parent`, `checksum`, `path_hash`, `path`, `storage`) VALUES('7', '13', '1532793539', '22866', 'd5402e151bcd48098f3ef2588dd105e2', '1532793539', '19', 'kbd.mo', '21351299', '', '82459aaad7fc0a71e8640a8e44bc903c', 'media/mmcboot/etc/skel/media/mmcboot/etc/skel/media/mmcboot/etc/skel/media/mmcboot/etc/skel/media/mmcboot/etc/skel/media/mmcboot/etc/skel/media/mmcboot/etc/skel/media/mmcboot/etc/skel/media/mmcboot/etc/skel/media/mmcboot/etc/skel/media/mmcboot/etc/skel/media/mmcboot/etc/skel/media/mmcboot/etc/skel/media/mmcboot/etc/skel/media/mmcboot/etc/skel/media/mmcboot/etc/skel/media/mmcboot/etc/skel/media/mmcboot/etc/skel/media/mmcboot/etc/skel/media/mmcboot/etc/skel/media/mmcboot/etc/skel/media/mmcboot/etc/skel/media/mmcboot/etc/skel/media/mmcboot/etc/skel/media/mmcboot/etc/skel/media/mmcboot/etc/skel/media/mmcboot/etc/skel/media/mmcboot/etc/skel/media/mmcboot/etc/skel/media/mmcboot/etc/skel/media/mmcboot/etc/skel/media/mmcboot/etc/skel/media/mmcboot/etc/skel/media/mmcboot/etc/skel/media/mmcboot/home/admin/media/mmcboot/home/admin/media/mmcboot/etc/skel/media/mmcboot/etc/skel/media/mmcboot/usr/share/locale/id/LC_MESSAGES/kbd.mo', '7');

:elephant:

De fait, dans /etc/skel il y a un alias media qui pointe vers /media.

Heu … il doit y avoir beaucoup de records dans la table oc_filecache !

cat /etc/yunohost/mysql # pour avoir le password root pour mysql
mysql -p # avec le password 
MariaDB [nextcloud]> use nextcloud;
MariaDB [nextcloud]> select count(*) from `oc_filecache`;
+----------+
| count(*) |
+----------+
| 18694382 |
+----------+
MariaDB [nextcloud]> quit

De fait … plus de 18 million de records, ça fait un peu beaucoup ça.

Pourquoi ?

je pense qu’avec l’utilitaire nand-sata-install que j’ai utilisé pour migrer le système de la microSD vers un disque SATA, le fstab est généré automatiquement comme ça

# cat /etc/fstab 
# <file system>					<mount point>	<type>	<options>							<dump>	<pass>
tmpfs						/tmp		tmpfs	defaults,nosuid							0	0
UUID=4554aa08-a77e-47ce-90fa-a19881d3232b	/media/mmcboot	ext4    defaults,noatime,nodiratime,commit=600,errors=remount-ro,x-gvfs-hide	0	1
/media/mmcboot/boot                             /boot		none	bind								0       0
UUID=6cf109a6-ef0a-4b1b-b39e-a230cafde6e4	/		ext4	defaults,noatime,nodiratime,commit=600,errors=remount-ro,x-gvfs-hide	0	1
…

Du coup, le contenu de la carte microsd est mapé pour tous les users de Yunohost dans /home/%user/media/mmcboot et si Nextcloud est installé, il index tout ça.
Et quand l’indexation arrive dans /home/%user/media/mmcboot/etc/skel/media ça part en boucle.

Du coup … j’ai édité la fstab pour remplacer media par mnt.

mkdir /mnt/mmcboot
nano /etc/fstab
…
# <file system>                                 <mount point>   <type>  <options>                                                       <dump>  <pass>
tmpfs                                           /tmp            tmpfs   defaults,nosuid                                                 0       0
UUID=4554aa08-a77e-47ce-90fa-a19881d3232b       /mnt/mmcboot    ext4    defaults,noatime,nodiratime,commit=600,errors=remount-ro,x-gvfs-hide    0       1
/mnt/mmcboot/boot                               /boot           none    bind                                                            0       0
UUID=6cf109a6-ef0a-4b1b-b39e-a230cafde6e4       /               ext4    defaults,noatime,nodiratime,commit=600,errors=remount-ro,x-gvfs-hide    0       1
…

Et redémarré.

yunohost tools reboot -f

Nettoyer mysql

Je me suis ensuite reconnecté pour vider la table oc_filecache.

cat /etc/yunohost/mysql # pour avoir le password root pour mysql
mysql -p # avec le password 
MariaDB [nextcloud]> use nextcloud;
MariaDB [nextcloud]> truncate `oc_filecache`;
MariaDB [nextcloud]> quit

Et j’ai ensuite laissé faire le cron.php de nextcloud.

Le lendemain je suis retourné voir où en était ma brique et la table co_filecache et c’est beaucoup mieux !

cat /etc/yunohost/mysql # pour avoir le password root pour mysql
mysql -p # avec le password 
MariaDB [nextcloud]> use nextcloud;
MariaDB [nextcloud]> select count(*) from `oc_filecache`;
+----------+
| count(*) |
+----------+
|    22668 |
+----------+
1 row in set (0.063 sec)
MariaDB [nextcloud]> quit

Et ma pitite Lime1 est à nouveau plus fluide.

:relieved:

4 Likes

ping @ljf , ptete à vérifier au cas où tu serais dans le même cas ^

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.