Il semble que certains des caches de tuiles du rendu Carto d'OSM.org ne fonctionnent pas correctement et ne cessent de se renvoyer des copies d'anciens rendus venant écraser les nouveaux reçus d'autres serveurs. Cela semble indiquer que certains serveurs ne sont pas correctement datés et ne parviennent pas à interpréter les dates d'expiration correctement dans les entêtes HTTP. Et cela pourrait expliquer aussi la surcharge actuelle des serveurs de rendu qui recalculent sans arrêt les mêmes zones sans parvenir à synchroniser les caches. Et cela se voit sur la carte finale (avec des vas-et-viens d'une version à l'autre des mêmes tuiles, même sans changement dans les données de la base OSM). Ou alors certains serveurs de rendus sont désynchronisés avec le flux des minute diff et ont à faire des "corrections" ou appliquent dnals leur propre base des données inconsistantes ne correspondant plus du tout à ce qui est dans la base principale, et incapables de prendre en compte des nouveaux changements (exemple: référence de certains ways à des noeuds inexistants marqués comme supprimés). Y-a-t-il des problèmes de synchro pour la réplication des bases et a-t-on un service qui permette de contrôler que tous les serveurs de bases (principale et esclaves), de rendus, et de caches sont bien synchronisés avec NTP et que leurs horloges sont cohérentes ainsi que les horloges internes des serveurs web (Apache ou Squid) ? Y a-t-il une programmation permettant de redémarrer les serveurs un par un régulièrement et vérifier leur intégrité et synchronisation, pour éviter ces "yoyos" très préjudiciables et aussi finalement limiter les requêtes et la consommation de bande passante et de ressources CPU/disque sur ces serveurs ? En tout cas la synchro entre serveurs ne semble pas sécurisée du tout, tout semble se faire sans aucune métadonnée de contrôle qui pourrait éviter d'écraser constamment des données correctement mises à jour par des données anciennes qui ne devraient plus être là. C'est peut-être un problème des systèmes de fichiers montés (particulièrement si le stockage des images se fait en réseau): des "fsck" réguliers semblent s'imposer aussi.
_______________________________________________ Talk-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-fr
