En effet j'ai eu le même problème et c'est récurent depuis hier. Le ven. 10 janv. 2020 à 06:17, Philippe Verdy <verd...@wanadoo.fr> a écrit :
> Les échecs comme dans le message ci-dessus (erreur DNS du proxy pour > joindre le serveur rails3 en upstream) ou des résultats > incomplets/tronqués, concernent en gros 1 requête sur 3 à l'API > (indépendamment de leur volume ou complexité), un des proxies est en panne, > on tombe dessus au hasard, ou il est mal configuré dans le load-balancer. > > Le ven. 10 janv. 2020 à 06:05, Philippe Verdy <verd...@wanadoo.fr> a > écrit : > >> [image: image.png] >> >> Le ven. 10 janv. 2020 à 05:59, Philippe Verdy <verd...@wanadoo.fr> a >> écrit : >> >>> je constate depuis aujourd'hui de très grosses lenteurs du serveur OSM >>> pour presque tout, au chargement des données dans l'éditeur (même sous iD >>> dans une toute petite zone, nombreux échecs, ou données partiellement >>> chargées et tronquées, sous JOSM, des listes de membres de relation >>> incomplètes ou des chemins longs auxquels manquent de nombreux points). >>> Lors de l'envoi, une partie des données est transmise, je passe mon >>> temps à revérifier (donc recharger péniblement) et corriger ce qui n'est >>> pas passé. >>> Et sous ID j'ai un message clair: ce sont les proxies qui retournent >>> après de longs délais des erreurs 502 donnant une raison erreur DNS: >>> problème de connexion avec le serveur central. >>> Cela semble être les proxies d'accès qui ont des problèmes, même si le >>> serveur est fonctionnel. >>> De plus les minute diffs sont anormalement en retard (plus d'1/2 heure >>> au moins quand les modifs sont habituellement visibles en 3 ou 4 minutes) >>> >>> Mais maintenant c'est carrément la panne: plus moyen de faire quelque >>> chose de fiable, même les vérifs après envoi mettent trop de temps ou se >>> rechargent trop lentement et partiellement, jamais deux fois les mêmes >>> résultats, d'où aussi l'apparition un peu partout de noeuds orphelins ou >>> d'objets laissés en doublon (je pense que ça touche pas mal de monde avec >>> les tentatives multiples de soumission à nouveau). >>> >>> [[ >>> Note: JOSM ne rapporte pas toutes les erreurs réseau, certaines sont >>> encore totalement silencieuses (sauf si on a ouvert la console Java, ce qui >>> n'est pas fait par défaut), méfiance car vous ne voyez pas forcément une >>> boite d'alerte après une exception pourtant bien détectée durant le >>> chargement ou l'envoi. Il est hautement recommandé de lancer JOSM avec la >>> console ouverte. >>> >>> Vérifiez votre panneau de configuration Java pour activer l'option >>> console de journalisation, même si cela a pour effet d'ouvrir une fenêtre >>> de plus qu'il ne faut pas fermer car on ne peut pas l'ouvrir à nouveau >>> ensuite. Malheureusement JOSM n'inclue pas lui-même sa propre fenêtre >>> console (ou l'inscription en backup vers un fichier log externe qu'on >>> pourrait consulter à tout moment), on n'a que la fenêtre console du lanceur >>> (fenêtre de commande dans laquelle on le lance via un shell, ou >>> Javawebstart. >>> >>> Cette option journal est bien pratique aussi pour gérer certains >>> conflits d'édition ou erreurs lors d'un envoir et trouver les ID d'objets >>> concernés, par fois de très grande liste qu'il faut garder en copie pour >>> les inspecter ensuite un par un ou par lot. La console Java permet au moins >>> de faire de copier-coller de ce qu'on veut garder. >>> >>> Avec l'éditeur iD, on a besoin parfois aussi de la console Javascript du >>> navigateur pour retrouver certaines erreurs non traitées par l'UI de >>> l'appli web et en trouver la cause ou le détail car certains messages des >>> serveurs ou proxies ne sont pas traitées: la console Javascript doit être >>> ouverte sinon les logs ne sont pas gardés en mémoire, mais on peut toujours >>> effacer la console à tout moment si on manque de mémoire et qu'on n'a rien >>> à garder. >>> ]] >>> >>> Là aussi c'est indispensable en ce moment et révèle que ce n'est pas un >>> problème de notre propre connexion internet jsqu'au front-end d'OSM, mais >>> quelquepart entre le front-end/proxy et les serveurs, dans le réseau >>> interne d'OSM. Et il semble que ce soit un problème de config DNS: les >>> front-end proxies ont du mal à maintenir ou rouvrir les connexions au >>> serveur, peut-etre une saturation mémoire ou d'un espace disque interne sur >>> les proxies, ou une panne sur un routeur ou un switch interne, ou une panne >>> chez Bytemark, l'hébergeur du domaine DNS osm.org. >>> >>> _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > -- Cordialement, Jérôme Seigneuret
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
