[OSM-talk-fr] Grosses lenteurs et panne des proxies du serveur de données OSM

[Philippe Verdy]

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 <verdy_p at wanadoo.fr> a écrit :

> [image: image.png]
>
> Le ven. 10 janv. 2020 à 05:59, Philippe Verdy <verdy_p at 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.
>>
>>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20200110/fe087804/attachment.htm>
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: image.png
Type: image/png
Taille: 20550 octets
Desc: non disponible
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20200110/fe087804/attachment.png>