osm-fr
Où en sommes nous des 3 rendus Humanitaire, OSM-fr et Cyclosm ?
Bonjour, un nouveau rendu transport est arrivé sur osm.org https://www.openstreetmap.org/#map=5/9.362/4.373&layers=O.
C'est l'occasion de revenir sur les 3 rendus "portés" par l'association osm-fr. Ces 3 services sont qualifiés de "services critiques" depuis la dernière AG, à savoir des services dont le dysfonctionnement entraine des conséquences "externes" à la communauté OSM. (pour rappel umap est considéré également comme un "service critique").
- Le rendu humanitaire a subi plusieurs coupures et longues interruptions au cours des mois d'avril-juin, il me semble que @cquest a confirmé au dernier CA que c'était résorbé et fonctionnel maintenant.
- Le rendu fr dans umap est de nouveau fonctionnel pour les zoom 19 et 20.
- Le rendu cyclosm est assez fortement attendu. Il y a une attente de savoir si nous (osm-fr) pouvons fournir ce rendu pour osm.org. Il y avait un "souci de taille de SSD" mais normalement tout a été upgradé par @cquest. Est-ce maintenant fonctionnel ?
Tout ceci pose plusieurs questions et je tente de résumer :
- avons nous actuellement l'infrastucture technique pour porter ces 3 rendus ?
- comment la maintenance peut-elle être simplifiée (même logiciel pour les 3 rendus, même OS, même ...) ?
- avons nous l'équipe d'humains nécessaire à assurer ce service "critique" ?
- quelles redondances des services pour "pallier" à un souci technique ?
- quel accueil des nouveaux dans le staff techniques ?
Et si d'autres questions je peux évidemment éditer ce post !
Cette issue c'est pour me (nous) faciliter le suivi et partager ce suivi ? Si cela vous semble inutile n'hésitez pas à le signaler, je n'ai pas encore tous les codes culturels des usages !
Pour suivi : https://listes.openstreetmap.fr/wws/arc/tech/2020-07/msg00008.html
Rendu humanitaire :
Gros chantier de fait dessus... migration vers nouveau SSD, recalcul des tuiles car l'expiration était non fonctionnelle. Il est revenu à la normale, il répond sans erreurs et avec des tuiles à jour.
Rendu FR :
Encore du chantier... mais déjà pas mal d'améliorations. Il y avait un problème de logique dans les priorités de rendu entre tuiles absentes, expirées, etc... Il répond désormais avec peu d'erreur, mais avec encore beaucoup de tuiles obsolètes (mais ça s'améliore).
Rendu cyclosm :
Son fonctionnement a été impacté ces derniers jours par un autre container (osmose) qui bouffait plein de ressources. La quantité de cache n'a quasiment aucun impact. D'ailleurs celui-ci est déjà supérieur que celui utilisé pour le rendu humanitaire (430Go). Il répond sans erreurs, avec peu de tuiles obsolètes.
Qualité globale de service :
Pour avoir une idée de la qualité du service rendu vu de l'extérieur, on a les graphes munin de mod_tile qui sont très utiles : https://munin.openstreetmap.fr/mod_tile-day.html
freshness of served tiles : les taux de "fresh" / "outdated" indiquent les tuiles qui sont à jour ou pas qui ont été renvoyée au client. Pour cyclosm, on est à plus de 95% de tuiles à jour renvoyées au client, 99.4% pour l'humanitaire et 56% pour FR.
mod_tile HTTP response codes : permet de suivre les erreurs renvoyées au client, le 404 étant le cas où la tuile n'existe pas dans le cache et n'a pas pu être calculée assez rapidement... et bien plus rarement quand le client demande une tuile au numéro farfelu. Là, on est à 0 ou quasiment (0.015% de 404 sur le rendu FR... qui était à 8% ces derniers mois).
Pour une idée encore plus précise de la qualité de service sur FR et humanitaire, il faudrait analyser les logs du cache à lyon... ce que j'envisageais de faire car une erreur retournée par le serveur de tuile peut être compensée par le cache.
merci beaucoup du boulot effectué. Sur le rendu humanitaire, j'ai du mal à comprendre cependant, il est blindé de carré gris. J'ai fait un enregistrement pour voir par rapport aux autres rendus et il me semble qu'il y a un souci : https://acloud2.zaclys.com/index.php/s/cQegCjdKEXeR5Si
en disant cela c'est pas pour nier le travail effectué évidemment, et je suis bien incapable de faire grand chose. Mais comme utilisateur, c'est pas fluide, y compris en comparant aux 4 autres sur osm.org
Ah... ça c'est pas normal... j'investigue pour voir si c'est pas le cache qui déconne, et bien sûr j'ai pas de souci quand je consulte de mon côté.
Avais-tu consulté déjà beaucoup de tuiles avant ? Il y a un limiteur (1800 tuiles/minute) pour éviter les aspirateurs, il est peut être réglé un peu trop bas.
Ok, trouvé... apache saturait sur osm13, il n'y avait que 64 slots configurés et resté en mpm_prefork, j'ai passé ça en mpm_event avec 256 slots.
CyclOSM bénéficie maintenant du cache de lyon (osm24).
osm23 et osm24 ont été upgradés par rézopole (passés à 30Go de RAM) et sur un nouveau serveur plus rapide.
Avant de donner un feu vert pour inclusion sur osm.org, on va faire du test de charge en rejouant les requêtes d'une journée entière pour le rendu humanitaire sur cyclosm... une sorte d'épreuve du feu, mais où c'est nous qui tirons ;)
Bonjour,
Il est probable que les travaux d'été ne sont pas finis, mais pour info, il y a des tuiles pas à jour (depuis au moins 2 ans, et c'est pas faute de demander à les afficher). par exemple :
- rendu HOT : https://b.tile.openstreetmap.fr/hot/20/527598/373891.png ou https://c.tile.openstreetmap.fr/hot/19/263799/186945.png
- rendu osm-fr : https://a.tile.openstreetmap.fr/osmfr/20/527598/373891.png (alors que la base est bien à jour et que le rendu osm-carto est correct).
Probablement parce que c'est à z19 et 20 ?
Visiblement c'est un problème au niveau de la base de données osm2pgsql d'osm13. C'est elle qui sert le rendu humanitaire ainsi que les zoom 13/14 et 20 FR.
Le polygone du parking https://www.openstreetmap.org/way/601767750/history n'est pas dans la base !
Par contre celui du chantier est toujours là... on a donc une vilaine désynchro dans les updates qui s'est produite à cette période. Impossible de la rattraper après 7 mois, il faudrait rejouer toutes les mises à jour entre temps pour une base cohérente.
La seule solution c'est un réimport complet...
En mode "bricole", j'ai forcé une mise à jour des objets actuels sur cette zone, pour cela j'atoute un tag bidon et je le retire, JOSM, va quand même renvoyer une nouvelle version identique des objets à l'API, donc on va recevoir un diff sur les objets actuels, mais pas sur le chantier.
En mode bricole, j'ai déjà "importé" des relations/ways/nodes dans une base de donnée (pas osm2pgsql) pour corriger des défauts. Ça permet d'éviter de modifier la bdd osm.
Sinon, ça fait un argument de plus pour installer le rendu hot sur d'autres machines, pour pouvoir mettre à jour la bdd d'osm13. Est-ce qu'on a assez de puissance de calcul pour déplacer hot sur osm25+osm11 ?
Je pense que ce sera plus simple de réimporter dans une base à côté de l'actuelle sur osm13 (on a la place). On peut aussi rediriger le renderd d'osm13 pour interroger la base PG d'osm165 au lieu de la base locale.
Sur le rendu humanitaire, j'ai du mal à comprendre cependant, il est blindé de carré gris.
Je crains que ce ne soit à nouveau le cas : https://www.openstreetmap.org/way/184478327#map=19/47.74245/-3.50135&layers=H
Curieusement la mini-carte des calques s'affiche au niveau 14 mais pas la carte : https://www.openstreetmap.org/#map=14/47.7421/-3.5128&layers=H
osm13 actuellement DOWN: https://github.com/osm-fr/infrastructure/issues/276
Si tu réponds à @vinber , "les 3 rendus sont opérationnels", ça m'étonnerait qu'il s'y oppose. Le rendu humanitaire vu d'osm.org marche à nouveau.
réimport fait pour résoudre https://github.com/osm-fr/infrastructure/issues/219#issuecomment-667900201 ou ticket dédié ?
oups oubli de fermeture, trouvé en cherchant les signalements concernant cyclosm pour faire le lien avec https://github.com/osm-fr/infrastructure/issues/411
je ferme ici donc