De plus le graphe munin indique clairemetn qu'Orm n'est pas hors
production mais est en cours de rattrapage de son retard de base de
données, donc qu'il a été réactivé (même si pour l'instant il ne produit
pas encore de tuiles puisque sa base est en cours de rechargement et
resynchronisation
Apparement les liens munin indiquent toujours que Orm est en prod, et aucun
lien pour rhaegal. Ces liens ne sont peut-être pas encore à jour, et
rhaegal est alors un nouveau serveur remplaçant orm (ce dont j'ai
maintenant un doute vu que le graphe munion le mentionne **maintenant**
comme 5e
Ok merci pour toutes ces clarifications. C'est un super compte rendu. Au
moins je comprends mieux ces histoires de délais de mise à jour de
tuiles... De mon côté c'est Scorch qui déconne. Bon week-end
Le sam. 11 août 2018 11:30, marc marc a écrit :
> Tu fais des suppositions de suppositions qui
Tu fais des suppositions de suppositions qui au final se transforment
en errer, un exemple :
Le 11. 08. 18 à 05:27, Philippe Verdy a écrit :
> Les 4 serveurs de rendus d'OMS.org sont "yevaud", "vial", "scorch",
> et "orm" (et non pas "rhaegal" ou c'est un ancien alias).
information de Tom
Voir aussi cette page de doc de wget au sujet des "timestamps".
https://www.gnu.org/software/wget/manual/html_node/Time_002dStamping-Usage.html
Et la note concernant FTP:
https://www.gnu.org/software/wget/manual/html_node/FTP-Time_002dStamping-Internals.html#FTP-Time_002dStamping-Internals
Le
Une piste à propos de Wget (voir http://www.gnu.org/software/wget/) qui
indique :
"Uses local file timestamps to determine whether documents need to be
re-downloaded when mirroring"
Note: "wget" peut utiliser HTTP ou FTP, mais les serveurs FTP sont connus
pour ne pas afficher la date UTC mais
Il toutefois que la synchro des diffs est basée sur les dates rapportées
par https://tile.openstreetmap.org/cgi-bin/debug
Il n'est pas clairement précisé dans ce "debug" comment est calculée cette
date : est-ce une date "UTC" ou une date locale ? Sachant que les
déménagement d'un serveur de
> le serveur utilisé actuellement dépend de la position géographique
> principalement mais peux aussi changer en cas de surcharge,
> info vérifiable en temps réel avec
> https://tile.openstreetmap.org/cgi-bin/debug
> les 2 serveurs ok : Yevaud et Vial
> les 2 serveurs affectés : Scorch et Rhaegal
Le 11. 08. 18 à 00:23, marc marc a écrit :
> les 2 serveurs ok : Yevaud et Vial
> les 2 serveurs affectés : Scorch et Rhaegal
arf cela concernait le bug osm2pgsql
et non la saturation des files des serveurs de rendu
___
Talk-fr mailing list
email séparé pour éviter la noyade avec les autres problèmes :)
ultra résumé pour ceux qui n'ont pas envie de tous lire :
- il y a des bugs en cours de résolution tant sur le rendu osm.org
que sur le rendu osm-fr
- faire un /dirty sur les zoom faible ne sert a rien car ignoré
- les zooms faible
10 matches
Mail list logo
