Lenteurs depuis la MàJ vers buster/YNH4

NB. : c’est normal d’avoir pleins de thread mysql et autre dans htop car par défaut il affiche les threads (ce que ne fait pas par exemple ‘top’ il me semble - du coup c’est effectivement très confusant la première fois qu’on lance htop sur un serveur qui a effectivement pleins de trucs qui tournent)

1 Like

Je veux dire éteindre son service. Par exemple :

systemctl stop airsonic

OU

systemctl stop rabbitmq-server

Vu les lenteurs que tu décris c’est normal que la webadmin se comporte mal.
Tu peux toutefois vérifier les versions de chaque composants de yunohost:

yunohost --version

Si t’as le sentiment que ça écris en permancence, check régulièrement au cas où le disque se remplis

df -h

J’ai désactivé des services, testé quelques trucs, rien ne change et maintenant mon iowait est passé à 67%. J’ai installé et lancé iotop qui m’informe que sql, nextcloud et jbd2 se tirent à la bourre en occupant tour à tour environ 99% des ressources io sans aucune trève.

En creusant un peu à propos de ce service jbd2 je constate que c’est courant qu’il encombre tout, et je me suis ensuite souvenu avoir suivi les conseils de ce thread en lançant un scan total par nextcloud. Je sais pas vous mais j’y vois comme un lien…

Là le serveur fait des backflips, j’ai demandé un reboot y’a 10 minutes il mouline encore… Dès que c’est bon j’essaierai de désinstaller/résintaller nextcloud proprement. Je risque de perdre ses données dans l’opération ? Ou ça ne touche qu’à l’application et nextcloud retrouvera ses petits après coup ?

Bon, j’ai lancé une sauvegarde totale après le reboot au cas où, et bien sûr elle est coincée depuis 20 minutes sur :

Backing up the MySQL database...
Declaring files to be backed up...
Loading installation settings...
Collecte des fichiers devant être sauvegardés pour l’application nextcloud … 

J’attends mais je n’y crois guère…


Et zou : 504 gateway timeout.

@Aristid essaie de sauvegarder NextCloud sans les fichiers. BACKUP_CORE_ONLY=1 yunohost backup create --apps nextcloud Tu pourras toujours copier les fichiers après.

Justement c’était ma question : est ce que désinstaller nextcloud touche aux fichiers qui y sont stockés ? Qu’en est il des apps nextcloud (calendar, deck, notes…) ?

Edit : ça coince encore au même stade (Backing up the MySQL database...)

Pour les fichiers et les notes ils sont sur le disque. Si tu installes un nouveau NextCloud sans restaurer une sauvegarde tu perdras seulement l’historique des versions de fichiers. Il faudra aussi lancer un scan complet (commande occ).

Les apps NextCloud telles que le calendrier, les tâches, les contacts stockent les données en base. Donc il faudrait que tu arrives à faire une sauvegarde (si ça passe sans les fichiers tant mieux). Attention si tu repars avec un NextCloud vide, le téléphone (DavX5) croit que tu as tout effacé sur le serveur et du coup il efface tout aussi sur le téléphone. J’ai eu le malheur de tester. Si tu as Thunderbird ou un autre client synchronisé capable de faire un export c’est plus prudent.

Personnellement, j’utilise un script qui fait un export des calendriers, contacts et tâches toutes les nuits : https://github.com/BernieO/calcardbackup

/home/yunohost.backup/scripts/calcardbackup/calcardbackup "/var/www/nextcloud" --like-time-machine 7 --remove 30

Ensuite je lance la copie des fichiers NextCloud, puis les backups Yunohost. J’ai séparé les backups en 3 pour une histoire de taille : système, apps Yunohost, NextCloud (core only). Puis je copie tout ça vers une autre machine (un disque branché sur la Freebox). Et une fois par semaine sur un disque hors de la maison.

Impossible de sauvegarder, ça timeout quand il veut sauvegarder la base sql… J’ai une sauvegarde Restic quelque part mais je suis pas certain de sa qualité, si rien d’autre ne marche je me fierai à celle là.

En attendant je passe beaucoup trop de temps à essayer de dépanner des trucs complètement hors de ma portée donc on se dirige tout droit vers une reinstall complète depuis 0 et je perdrai ce que je dois perdre…

Yo ! Quelques nouvelles depuis mes déboires récents…

J’ai identifié le coupable et tout est revenu à la normal : c’était bien jdb2 qui plombait toute la machine en passant au peigne fin tout le DD, d’où l’iowait énorme et les lenteurs qui en découlent. D’après quelques recherches c’est le service de journalisation/indexation ext4 (si j’ai bien compris c’est le service du kernel qui fait l’inventaire de toute ce qu’il y a sur du disque dur pour bien ranger les ptits morceaux). Donc je vois deux possibilités de causes du réveil soudain et lourd de ce service :

  • la migration vers Buster qui a du mettre à jour le kernel avec lui et donc jdb2 s’est mis à ranger

ou

  • le branchement d’un DD externe et la création de liens symboliques vers celui ci et jdb2 a voulu tout ranger là bas aussi

ou un mélange des deux. Ou peut être rien de tout ça, ça n’est que mes déductions. Bref, le fait est que maintenant que jdb2 a fini de faire grincer du disque dur (ça aura pris une semaine quand même) et que le tout répond normalement. J’en ai profité pour tout mettre à jour proprement, virer airsonic qui est une usine à gaz, et tout roule.

Merci à tous !

1 Like

J’avais encore un doute alors j’ai installé netdata pour pouvoir surveiller ça autrement que par du terminal pas hyper pratique…

Verdict : toutes les heures tout s’emballe pendant 15 minutes. CPU à 100%, iowait qui atteint 80% et sql en tête de l’utilisation du CPU. Chose étonnante : quasiment jamais aucune écriture sur le DD, que de la lecture à fond la caisse.

En fouillant un peu dans les graph SQL, je tombe sur

**read rnd next**, the number of requests to read the next row in the data file. This value is high if you are doing a lot of table scans. Generally this suggests that your tables are not properly indexed or that your queries are not written to take advantage of the indexes you have.


Je fais fausse route ou y’a un truc qui coince avec sql ?

Tu devrais peut être cherché dans les cron pour voir si tu as une tâche qui se lance toutes les heures.
Le cron de nextcloud est lancé toutes les 15min, mais peut être que l’opération se fait chaque heure en réalité …

A priori rien de spécial, dans le cron.hourly j’ai juste le script fakeclock qui doit pas consommer des masses… Est ce une bonne idée de désactiver le service cron pour quelques heures pour voir si ça change quelque chose ?

Bonne pioche : j’ai désactivé le service cron pour la journée et aucun pic d’activité. Reste à trouver LE coupable mais comment ?

Alors j’ai fini par désactiver cron totalement, puis je me suis creusé la tête : en poussant un peu les recherches j’ai fini constaté une limite de temps dans le cronjob de nextcloud à 14 minutes, ce qui coincide exactement avec les pics d’activité sur le serveur. J’ai donc fouillé les issues de nextcloud et…

FOUND IT

Ça n’était donc pas la migration vers Buster qui a déréglé un truc, mais la mise à jour de nextcloud.

Je vais passer le cronjob nextcloud en daily et il foutra moins souvent la zone, quand ça sera résolu je le repasserai normal.

1 Like

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