[OSM-talk-fr] Statut du Wiki: bogues sévères de MediaWiki

Philippe Verdy verdy_p at wanadoo.fr
Mer 5 Juil 01:45:45 UTC 2017


Note: cette page de doc peut aider pour tenter de résoudre les liens
manquants

https://www.mediawiki.org/wiki/Manual:RefreshLinks.php

Attention cet outil par défaut va commencer par traiter toutes les pages du
wiki à commencer par celle avec page_id=1 (les pages sont traitées dans
l'ordre croissant des "page_id" trouvés)

L'outil peut consommer de plus en plus de mémoire et finalement échouer, il
peut aussi consommer beaucoup de ressources sur le serveur. On peut
cependant le lancer pour traiter par petits paquets, par exemple au maximum
1000 pages à la fois (ou moins si le wiki est sur un petit serveur moins
puissant que ce soit son moteur PHP ou sa base MySQL ou MariaDB) avant de
mettre en attente et reprendre, jusqu'à arriver au dernier ID de page dans
la base.

Un petit script shell devrait pouvoir interroger l'id minimum et l'id
maximum utilisé dans la base SQL pour faire tourner une boucle dans un
petit script shell insérant les pauses nécessaires entre deux lancements du
script PHP. Ce script peut ensuite être inséré dans une tâche cron quand
vous aurez une idée du temps total d'exécution pour parcourir la base
entière des pages : commencez doucement avant d'automatiser et surveillez
les premiers lancements pour mesurer les performances, si vous ne voulez
pas arrêter le serveur wiki ou le passer en read-only pendant des heures !



Le 5 juillet 2017 à 03:01, Philippe Verdy <verdy_p at wanadoo.fr> a écrit :

> Pour info:
>
> https://wiki.openstreetmap.org/wiki/User_talk:Verdy_p#Platform_Status
>
> (je mentionne cette discussion car plusieurs m'ont posé des questions sur
> le "Platform Status" du Wiki et j'y ai répondu, puis j'ai alimenté ce que
> j'ai pu trouver comme pistes sur le traqueur de bogues de MediaWiki)
>
> Je pense que je vais migrer cette section de ma page de discussion dans
> une page dédiée.
>
> Je pense que même les admins du wiki OSM ne sont pas tous au courant
>
> Cette section est en grande partie en anglais, mais la maintenance du wiki
> OSM est maintenant très délicate voire quasi impossible: les catégories ne
> sont plus du tout mises à jour, le suivi des liens est impossible après
> avoir renommé une page quelconque.
>
> Tout ce qu'on peut faire c'est tenter de suivre les pages modifiées qu'on
> a déjà dans sa liste de suivi (mais la mise à jour de la liste perso de
> suivi est elle aussi boguée !)
>
> Depuis le déploiement de la version 1.28.0 (puis de la version 1.18.2 qui
> ne corrige pas l'anomalie mais l'a aggravé) il est presque impossible de
> vérifier la cohérence des liens des catégories, et même de détecter des
> contenus "spammés" indésirables.
>
> Et des tas de modifications sur le wiki ne sont plus signalées à ceux qui
> suivaient des pages. Les listes de suivi perso sont également corrompues
> (avec des tonnes de doublons!) ou explosent au delà de la taille maximale
> avec ensuite des pertes irréparables.
>
> Des mails de notification ne sont également pas envoyés (je n'ai pas fait
> le point de tous les cas possibles).
>
> En gros MediaWiki 1.28 a complètement bouleversé la façon dont des mises à
> jour de la base sont maintenant sous-traitées en arrière-plan (sans
> attendre qu'elles finissent durant le temps de la transaction utilisateur
> sur le web), dans le but d'améliorer le temps de réponse lors de la
> navigation et éviter des "reflows" multiples dans le navigateur au fil des
> données reçues. En gros tout ce qui peut être différé sans bloquer l'envoi
> de la page HTML formatée est mis en attente dans une tache différée.
>
> Ensuite quand la session HTTP de l'utilisateur se termine le serveur peut
> continuer à effectuer un certain nombre de tâches différées (cette quantité
> est paramétrable) et sinon au delà d'un seuil la tâche différée est
> convertie en "job" insérée dans la "job queue". Ces jobs s'exécuteront plus
> tard (éventuellement des heures après) par une tâche programmée (cron) sur
> le serveur qui ira lire la base de données pour les trouver puis les
> exécuter. Ce qui est nouveau est que ces tâches programmées peuvent
> elles-même repousser d'autres tâches différées qui seont éventuellement
> converties en "jobs" à exécuter eux aussi plus tard.
>
> Ce système est complètement défaillant, notamment pour la mise à jour des
> catégories, et le suivi des liens ("what links here") ou encore pour les
> traqueurs de contenus indésirables et certaines notifications qui ne
> fonctionnent plus dans le nouveau système, à cause de préconditions
> (assumptions) fausses:
>
> selon les cas cela cause des erreurs fatales (visibles dans les logs du
> serveur) ou bien l'annulation silencieuse de tâches différées (qui ne sont
> pas enregistrées dans la base comme elles auraient du l'être), ou bien des
> tâches différées trop nombreuses qui ne sont pas converties en "jobs", ou
> bien qui ne sont pas ôtées de la file d'attente et sont répétées (ce qui
> peut causer l'explosion de la job queue pour certaines requêtes
> "récursives".
>
> Dans ma page de discussion je suggère d'arrêter la version MediaWiki 1.28
> et revenir à la version 1.27 (qui avait quelques bogues aussi dans la
> "JobQueue" mais moins critiques et pour lesquels on avait un contournement
> facile (au pire un simple "null-edit" sur la page qu'on venait juste de
> modifier). Mais là on n'a aucun contournement et des centaines de milliers
> de tâches différées ont été perdues depuis fin mai, ou ont été tentées
> plusieurs fois (3 fois avec échec) avec un abandon automatique (cela a
> causé il y a quelques jours une explosion combinatoire des tâches avec
> plusieurs centaines de milliers de jobs dans la job queue, qui ont tous
> échoué et ont tous été abandonné.
>
> Maintenant la job queue est vide (ou pratiquement) et des tas de mises à
> jour ne se font plus du tout et sont perdues silencieusement la plupart du
> temps (invisibles même dans les logs administrateur sur le serveur).
>
> Les développeurs de MediaWiki sont en train de concevoir des "moulinettes"
> PHP pour rescanner les pages: cela sert temporairement à de la maintenance
> manuelle (du côté des wikis de MediaWiki, certaines moulinettes sont
> actives pour réparer les dégats mais elles sont très gourmandes en
> CPU/réseau/mémoire/requêtes SQL et les performances s'en ressentent: ce
> n'était pas le but de la version 1.28 qui devait accélérer la navigation
> sur le wiki. Mais il n'est pas possible d'employer ces moulinettes en
> continu sur le wiki OSM (le serveur n'est pas assez puissant pour ça). Mais
> il faudra bien prévoir un jour ou l'autre un arrêt temporaire du wiki pour
> faire de la maintenance hors ligne (et ça prendra des heures... voire des
> jours avec le serveur actuel et il faudra prévoir des réparations
> partielles successives avec des arrêts à programmer plusieurs jours ou sur
> plusieurs semaines pour rattraper les anomalies accumulées, et ceci même si
> on revient en version MW 1.27).
>
> J'ai donné la liste des anomalies relatives à ces problèmes sur ma page de
> discussion, pointant sur le Phabricator de MediaWiki.
>
> Tout ce que je peux dire aussi, c'est que si vous gérez d'autres petits
> wikis perso, il vaut mieux ne pas utiliser la version 1.28 actuelle (ni les
> versions suivantes 1.29 et 1.30 qui ne sont pas plus corrigées sur ce
> point) mais rester en version 1.27 maxi. La version 1.28 a beau être
> affichée par MediaWiki comme la dernière version "stable", elle ne l'est
> pas du tout et cela complique sérieusement la maintenance de base des
> contenus par leurs contributeurs réguliers et même pour les admins de ce
> wiki (même ceux ayant accès à la base SQL ou aux tâches cron et au niveau
> natif du système Unix/Linux sur un serveur dédié ou dans une VM à eux).
>
> Certains patches ont été faits pour la version 1.27 et ils fonctionnent et
> il faut aussi faire attention au paramétrage de MediaWiki (activation ou
> pas des "jobs" ou des "deferred updates"). ceux pour MX 1.28, 1.29, 1.30 ne
> marchent pas encore (et ce sont surtout des beta-tests ou ils ne
> fonctionnent en partie que pour Wikimedia avec une implication forte de son
> équipe d'adminstration système, et des patches spécifiques mais non
> portables pour contourner certains problèmes en utilisant plusieurs
> serveurs complémentaires et des sycnhronisations complexes entre serveurs)
>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20170705/3685a9dc/attachment.htm>


Plus d'informations sur la liste de diffusion Talk-fr