Journal Upgrade Nextcloud 21.0.1, PHP et le temps perdu

Posté par  . Licence CC By‑SA.
Étiquettes :
32
13
avr.
2021

Hello.

Un petit retour d'expérience qui fera peut-être gagner du temps à certains…

J'ai lancé l'upgrade de Nextcloud vers la dernière version hier matin, et ai galeré un moment…

La mise à jour prend des heures (littéralement) et stoppe au bout d'un moment. J'arrive à me connecter au serveur en ssh, et là…
PHP part en sucette, il pompe toute la mémoire et le cpu, le cron qui habituellement tourne rapidement part en oom au bout d'un certain temps, avec 15 tâches en même temps, le serveur est au bord de l'agonie…

J'arrive à retirer le job du crontab, je kille toutes les tâches php, et essaye de faire l'upgrade en cli. Le truc tourne, n'affiche rien même en -vvv et au bout d'un moment : "Killed"

Je cherche un peu sur internet, et trouve cette page : https://help.nextcloud.com/t/solved-occ-command-php-fatal-error-allowed-memory-size-of-xxx-bytes-exhausted/108521/17

Et surtout ce passage :

I had APCu activated in the nextcloud config.php. It seems I didn’t have apc.enable_cli=1 in /etc/php/8.0/cli/conf.d/20-apcu.ini. After I added that line to the file occ worked and there was no segmentation error anymore.

Il semble que la nouvelle version de Nextcloud demande à avoir APCu activé dans PHP, ce qui n'était pas le cas par défaut dans ma distro…

J'active, je relance l'upgrade, et tadaaa!! Tout fonctionne correctement.

Il ne reste plus qu'à réactiver mon cron…

Je sais, j'aurais dû faire plus attention, et lire toute la doc avant de lancer l'upgrade. Mais ce point ne semble pas dans la doc, et je n'ai pas vu de message informant de ce changement dans l'annonce de version.

  • # Oulala

    Posté par  (site web personnel) . Évalué à 9. Dernière modification le 13 avril 2021 à 12:40.

    Dépendre explicitement d'APCu et ne même pas faire de check au runtime, ça me paraît être une sacré erreur. De plus, je me demande bien pourquoi ils peuvent le rendre obligatoire ? Au mieux, ils peuvent essayer de s'en servir de cache (mais c'est PAS bien, enfin si c'est pour des gros caches, c'est pas fait pour ça, c'est fait pour des petites choses) mais de plus, leur algo de mise en cache est probablement moisi, si le backend ne répond pas ou ne renvoie rien, il faut faire un fallback sur un recalcule des données nécessaires, sans planter.

    Enfin bref, y'a quelque chose qui cloche dans leur implémentation.

    • [^] # Re: Oulala

      Posté par  . Évalué à 5.

      De plus, je me demande bien pourquoi ils peuvent le rendre obligatoire ?

      C’est pas obligatoire, il y a plusieurs méthodes documentées : APCu, Redis et Memcache (personnellement j’utilise Redis).

      • [^] # Re: Oulala

        Posté par  (site web personnel) . Évalué à 0.

        Ah, donc choisir une implémentation basée sur un serveur ou extension supplémentaire est obligatoire :)

        • [^] # Re: Oulala

          Posté par  . Évalué à 1.

          Non.

          • [^] # Re: Oulala

            Posté par  (site web personnel) . Évalué à 1.

            Et bien si, le server redis, je ne parle pas d'une autre box physique.

            • [^] # Re: Oulala

              Posté par  . Évalué à 4.

              L'activation du cache n'est pas une obligation dans Nextcloud (même si c'est fortement recommandé un peu partout dans la doc et l'interface d'admin). Tu peux fonctionner sans ; par contre, si tu le fais, tu as les trois solutions ci-dessus.

              • [^] # Re: Oulala

                Posté par  (site web personnel) . Évalué à 1. Dernière modification le 14 avril 2021 à 15:58.

                Oui désolé j'ai répondu un peu vite, je voulais dire "dans ton cas, celui où tu as choisi Redis, alors tu es dépendent d'un autre serveur", mais bref. Ça ne change en rien que je trouve ça relativement mal documenté, mais après vu que j'ai passé des heures dessus, ça à l'air suffisant après trois relectures (essayez donc la doc de Microtik, faut s'accrocher sec par endroits).

        • [^] # Re: Oulala

          Posté par  (site web personnel) . Évalué à -1.

          Si Nextcloud ou ses pré-requis ne te convient pas … Ne l'installe pas, ne l'utilise pas !

          Encore une fois Redis, Acpu, … ne sont pas requis.

          Tu as juste envie de râler après Nexcloud. Il t'a porté préjudice ? Tu as un passif avec ?

          Jérôme.

          • [^] # Re: Oulala

            Posté par  (site web personnel) . Évalué à 3.

            Je ne râle après Nextcloud, comme je le dis plus bas, c'est un excellent logiciel. Cependant, je reste surpris que ce genre de bugs puisse apparaître sur une mise à jour, et en vrai, ça ne m'étonne qu'à moitié: durant tout le temps où je l'ai utilisé (avec plaisir, je tiens à le dire) je n'ai jamais eu une seule upgrade qui s'est bien passée, dans la majorité des cas j'en suis arrivé à faire du step debugging dans le code, pour trouver ce qui échouait (souvent des erreurs bêtes, par ailleurs, mais quasi-systématiquement qui nécessitaient de patcher).

            Et le constat sur le fait qu'ils ont l'air d'utiliser APCu en mode YOLO reste assez vrai, cf. ce que je dis plus bas, la façon dont ils l'utilisent est bancale.

  • # Commentaire qui n'apporte rien

    Posté par  . Évalué à 3.

    Mais j'ai eu la même chose (et j'ai eu peur dans un premier temps que mon VPS soit devenu sous dimensionné pour cette version de Nextcloud, ce qui arrivera bien un jour…).

    Et j'ai mis un certain temps à trouver l'explication et le correctif : l'ajout de apc.enable_cli=1 dans /etc/php/<VERSION>/cli/conf.d/20-apcu.ini.

  • # la doc

    Posté par  . Évalué à 7.

    certes, c'est peut être un peu caché, mais c'est documenté depuis belle lurette.. https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/caching_configuration.html?highlight=apc#id1

    cf https://github.com/nextcloud/documentation/pull/830 et https://github.com/nextcloud/documentation/pull/2137

    mais oui, un check au runtime aiderait :)

    • [^] # Re: la doc

      Posté par  . Évalué à 2.

      J'ai pourtant suivi cette doc pour configurer mon cache… Je dois avoir un problème d'yeux pas en face des trous ><

      Par contre, je n'avais pas de problème avant cette version, ce qui est étrange. Il y a dû y avoir un changement qui a fait passer le truc de "ça peut arriver" à "c'est tout le temps".

    • [^] # Re: la doc

      Posté par  (site web personnel) . Évalué à 0.

      C'est sûr mais c'est résolument débile que l'implémentation par défaut ne soit pas dans la base de donnée, sachant que Nextcloud en requière une, et que pour le commun du mortel, c'est à dire la petite gens qui ne fait pas de cloud, qui ne gère pas des milliers d'utilisateurs concurrents, ça serait une implémentation efficace et qui fonctionnerait sur tous les environnements, et ne nécessiterait pas de configuration.

      • [^] # Re: la doc

        Posté par  (site web personnel) . Évalué à 5.

        C'est pas un peu violent "résolument débile" ?

        Sinon le cache n'est pas requis :

        https://docs.nextcloud.com/server/21/admin_manual/configuration_server/caching_configuration.html#memory-caching

        If you do not install and enable a local memcache you will see a warning on your Nextcloud admin page. A memcache is not required and you may safely ignore the warning if you prefer.

        Ensuite redis ou memcached c'est effectivement utile et efficace, mais tu peux t'en passer.

        Jérôme.

        • [^] # Re: la doc

          Posté par  (site web personnel) . Évalué à 7.

          Ouais alors:

          • ils documentent que ce n'est pas requis,
          • ils ne documentent pas comment le désactiver,
          • des gens se retrouvent bloqués lors d'une mise à jour.

          Ça me semble un peu bancale tout ça. Une implémentation par défaut sur le SQL aurait fait le job, c'est ce que beaucoup de frameworks ou outils font quand on choisit de ne pas configurer.

          Un cache sur le SQL souffrira que si le serveur est lui même en souffrance mais sur une utilisation plus calme va offrir le même niveau de performance qu'un cache sur un service dédié (Redis, Memcache ou autre).

          Le cache dans un pool APCu est relativement dangereux, si on décide de scaler (passer à l'échelle horizontalement) on va avoir des sérieux problèmes, car il ne sera pas partagé entre les différents front, et en cas d'effacement du cache on va se retrouver avec des front qui auront des caches désynchronisés, ce qui force à passer par un composant supplémentaire qui permet de servir de sémaphore, pour éviter les accès concurrents, mais aussi d'historique de synchronisation, pour éviter les problèmes de désynchronisation.

          Utiliser APCu dans une conf par défaut n'est absolument pas une bonne pratique, c'est offrir par défaut la plus instable et dangereuse des implémentations.

          • [^] # Commentaire supprimé

            Posté par  . Évalué à 1. Dernière modification le 13 avril 2021 à 16:30.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: la doc

              Posté par  (site web personnel) . Évalué à 2.

              Mon serveur fonctionne avec php-apcu uniquement et je n'ai jamais eu aucun problème

              Bien entendu, avec un PHP correctement configuré de base c'est normal que ça marche. Et le fait même que tu précises "mon serveur" indique que tu n'es pas dans un scénario ou les desync sont possibles, tout simplement parce que tu ne disposes que d'un serveur.

              Mais attention cependant, le cache APCu du cli, et le cache APCu du serveur web ne sont pas les mêmes, il est très probablement inutile en cli d'ailleurs puisqu'il ne persiste pas au delà de l'exécution de la commande.

              Donc même dans ton scénario, pendant un temps, la desync est possible: si tu lances une commande cli qui effectue des modifications dans le cache, ton serveur web restera sur l'ancienne version du cache, puisqu'il dispose de son propre cache en mémoire partagée avec lui même.

              J'espère honnêtement que l'équipe de nextcloud a prévu au moins un sémaphore sur fichier, ou dans la base, ou n'importe où qui persiste, pour indiquer une date seuil de validité des enregistrements du cache, afin que ça n'arrive pas.

              • [^] # Re: la doc

                Posté par  (site web personnel) . Évalué à 3. Dernière modification le 13 avril 2021 à 17:10.

                Juste pour info: de manière générale mettre un cache dans APCu est dangereux, les développeurs ne pensent souvent pas à tous ces petits détails, c'est extrêmement compliqué que le gérer intelligemment et sans effet de bord.

                D'ailleurs quand je regarde l'implémentation https://github.com/nextcloud/server/blob/905e1918d2796b9a79025283cd6edf2c40f49d77/lib/private/Memcache/APCu.php ça semble un peu faiblard de prima-bord, j’espère qu'ils ont un contrôleur ou un décorateur autour qui gère ces problématiques (d'ailleurs, un décorateur est probablement le meilleur pattern pour s'en sortir parce que de fait il devient utilisable pour les autres implémentations).

                • [^] # Re: la doc

                  Posté par  (site web personnel) . Évalué à 2.

                  D'ailleurs en fait quand je vois l'implémentation de base https://github.com/nextcloud/server/blob/905e1918d2796b9a79025283cd6edf2c40f49d77/lib/private/Memcache/Cache.php le fait qu'ils servent des méthodes magiques de l'interface ArrayAccess m'indique que lorsqu'ils ont écrit ce code (c'était peut être il y a longtemps) ils ne connaissait finalement que peu ou mal les bonnes pratiques et l'outillage de la communauté PHP en général.

                  • [^] # Re: la doc

                    Posté par  . Évalué à 2.

                    Tu dois pouvoir proposer une pull request, il l'accepterons sans doute.

                    • [^] # Re: la doc

                      Posté par  (site web personnel) . Évalué à 10. Dernière modification le 13 avril 2021 à 23:04.

                      TL;DR ("Trop Long; Pas Lu" pour les francophones refractaires): ce n'est simplement pas vrai, de manière générale dans le libre, une PR est rejetée par défaut.

                      Version longue:

                      C'est un peu plus compliqué que ça, je contribue à pas mal de logiciels open source, mais il y a toujours une communauté, des développeurs écoutés et tout puissants au milieu, et sur ce genre de logiciel plus que d'autre, qui est un produit mené par une société et non un logiciel dont le développement est basé sur la "do-ocratie", une roadmap claire et définie sur le long terme par une équipe au coeur, intriquée à la société qui développe le produit.

                      Et sans tenir compte que bien souvent, malheureusement, le premier réflexe d'un développeur est une méfiance systématique envers les nouveaux développeurs, plus spécifiquement quand ils font des critiques attraits au design même du logiciel.

                      Je pense que tout ce qui touche au fondement du logiciel (sans vouloir faire de jeu de mot), et la gestion du cache dans une application dont la performance est critique en fait partie, est sujet à ne pas évoluer sauf si un développeur déjà connu de l'équipe se saisi du sujet sur le long terme, ou apporte une idée de génie avec un proof-of-concept qui n'en est pas un sur lequel il a déjà travaillé des jours durant.

                      Bref, je n'ai aujourd'hui ni le temps ni l'envie de passer par toutes étapes d'introduction, gain de confiance, "beginner issues", et tout ce qui s'en suit, un process qui dans l'absolu dure des jours, semaines, mois, tout ça pour dénoncer une erreur de débutant sur la gestion du cache (ce qui serait relativement mal pris, connaissant l'égo de pas mal de développeurs) pour une application que je n'utilise plus depuis un an et des bananes.

                      Nextcloud est un excellent produit, de bonne qualité, je l'ai utilisé depuis que le fork a été officiellement annoncé (j'utilisais déjà Owncloud avant) et je l'ai beaucoup apprécié, cependant je suis repassé sur un ensemble de logiciels plus simples qui proposent des solutions unitaires, atomiques, à chaque besoin auquel répondait Nextcloud parce que c'est plus facile à maintenir comme ça. Nextcloud, bien qu'excellent, à un problème systématiques sur les mises à jour (j'ai du aller débugguer et patcher moi même moult fois, si ce n'est à chaque mise à jour).

                      Bref, je n'ai pas l'envie d'aller contribuer à ce logiciel, je le fais déjà sur suffisamment d'autres pour avoir payé ma dette au logiciel libre. Bien qu'étant un excellent logiciel dans son ensemble, ce n'est pas parce que je ne vais pas y contribuer que je n'ai pas le droit d'en soulever les points noirs et donner un avis critique (surtout que ça touche directement à mon métier quotidien), si le logiciel n'en valait pas la peine je n'en parlerais juste pas.

  • # Merci !

    Posté par  (site web personnel) . Évalué à 3.

    Je vais regarder ça avant de lancer la mise à jour…

  • # D'autres soucis

    Posté par  (site web personnel) . Évalué à 4.

    De mon coté, l'application Talk / Spreed faisait crasher la mise à jour vers Nextcloud 21. J'ai dû désinstaller l'application, mettre à jour Nextcloud, puis la réinstaller (l'historique des conversations est restée).

    Heureusement pour moi que j'ai pris l'habitude de faire un snapshot du conteneur où tourne Nextcloud avant de faire les mises à jour …

  • # Nextcloud, pénibilité à administrer et gourmandise en ressources

    Posté par  . Évalué à 6. Dernière modification le 13 avril 2021 à 14:31.

    Nextcloud est tellement pénible à administrer et à mettre à jour que ça fait partie des rares trucs que j'héberge sur une instance Yunohost, pour profiter de ses fonctionnalités de mises à jour en un clic.

  • # Redis

    Posté par  . Évalué à 3.

    J'ai aussi fait la monté de version récemment et je n'ai pas eu de problème. Ma config est complètement sur Redis, pas d'APCu en vue.

  • # Stratégie Marketing

    Posté par  (site web personnel) . Évalué à 5.

    La stratégie marketing de Nextcloud est d'attirer les utilisateur personnel à l'utilisation familiale, ou dans des petites boites. Laisser les gens parler d'eux dans les forum et autre (comme ici). Et espérer que les sysadmin des plus grosse boites en entende parler pour qui un service professionnel est requis et qui vont donc payer.

    Il faut bien comprendre la différence entre les deux groupes: les premiers installent Nextcloud sur des petites machine genre RaspberryPi ou serveur partagé avec une vielle version de PHP, ils ont en général entre 1 et quelques dizaines d'utilisateurs.
    Alors que les grosses boites ou universités ont des milliers voir des centaines de milliers d'utilisateurs et stockent des téraoctets ou des pétaoctets sur de gros serveurs, souvent distribués, administré par des professionnels à temps plein.
    Le challenge est de rendre heureux les deux catégories d'utilisateurs et tout ceux au milieux.

    Vu que l'argent viens des grosses configuration, des fonctionnalités sont ajoutées qui demande pas mal de ressources. Et PHP n'aide pas beaucoup au niveau performances.
    Mais PHP est bien pratique car c'est disponible presque partout… dans plein de configurations différentes avec des modules différents, des système de fichiers différent et base de données différente donc parfois c'est difficile de faire tout fonctionner de manière performante.

    Par exemples, pour mes besoin persos, un petit serveur avec une base de donnée sqlite va très bien et est facile à installer. Et ça marche. Mais sqlite avec des installations moyennes est super lent, donc il essayent de détecter les config lentes et de mettre des avertissement sur la page d'admin quand il détectent un truc lent. Mais c'est pas toujours possible de détecté tout les problèmes de performances et certains ne regardent pas les conseil de la page admin ou de la doc :-)

    • [^] # Re: Stratégie Marketing

      Posté par  . Évalué à 2.

      pour ce qui nous concerne, notre instance Nextcloud est connectée à un annuaire LDAP d'entreprise avec entre 1200 pour l'une des branches et 15000 utilisateurs. Malheureusement, pour une raison que j'ai du mal à expliquer, si je connecte à la branche globale de l'annuaire, les performances sont très mauvaises : trop de requêtes LDAP unitaires plutôt qu'une seule et unique. Alors on est obligés de brider notre instance à une sous-branche de l'annuaire.

      Est-ce que quelqu'un d'entre vous a aussi cette expérience ?

  • # top ça a sauvé ma journée !

    Posté par  . Évalué à 3.

    merci :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.