mise à jour des donnnées pour le rendu humanitaire

[Marc-marc-marc]

@pnorman said
The Humanitarian layer on OSM.org hosted by OSM France, has data that is >3 months old. Is this a known issue with plans to resolve it? As an example, see https://tile-b.openstreetmap.fr/hot/18/41584/89751.png and https://tile.openstreetmap.org/18/41584/89751.png building shapes

• réajout de chronic sur les crons des 2 ct pour n'avoir que les mails utile à l'avenir
• un pbf incomplet dans /root -> supprimé
• /root/osm2pgsql-import-tools/flat-nodes.raw -> déplacé dans /data/work/osm2pgsql pour plus de lisibilité
• /data/work/osm2pgsql/expire_list il faudrait voir sur les autres serveurs s'il reste une trace des commandes de nettoyage qui ont été perdues ou mettre en place le meme méccanisme que sur osm165 osm166
• déplacement /root/osm2pqsql dans /data/project/osm2pqsql (le répertoire existait mais était vide)
• branchement temporaire de hdm à la bdd osm25 à titre de secours
• téléchargement dernier planet
• réimport en cours
• maj os
• suppression de l'ancienne version osm2pgsql compilé au profit de celle du dépot deb plus à jour
• maj postegresql
• annulation du branchement temporaire de hdm à la bdd osm25 à titre de secours
• import terminé
• index manquant dans le script créé à partir de l'historique des commandes
• maj des données de la bdd : le pbf importé ne date pas d'aujourd'hui, il faut résorber le lag
• invalider les tuiles du cache
• mettre à jour les premiers niveaux de zoom (jusqu'à 12)
• l'espace disque pour les tuiles a été fortement réduit divisé par 4, à voir si c'est toujours pertinent alors qu'il y a qlq To de libre sur le serveur
• proposer les PR (proposition d'amélioration des scripts) avec mes modifs
• il y a d'autres tickets à propos de la diversité des configs, ce qui fait qu'un bug résolu sur un serveur ne profite pas aux autres
• tester
• réactiver les crons
• supprimer la redirection faite sur le frontal
• regénérer les premiers niveaux avec les données à jour

[Marc-marc-marc]

5k mail root sur le ct de rendu et autant sur le ct bdd

• réajout de chronic sur les crons des 2 ct pour n'avoir que les mails utile à l'avenir... les mail de ceux-ci s’arrêtent en 2022 sur les 2 CT

espace / saturé, principalement par

• un pbf incomplet dans /root -> supprimé
• /root/osm2pgsql-import-tools/flat-nodes.raw 64Go -> déplacé dans /data/work/osm2pgsql pour plus de lisibilité
• /data/work/osm2pgsql/expire_list 53G qui garde tous les fichiers depuis l'éternité... chose que j'avais aussi déjà corrigé -> supprimé 2021 2022-01 2022-02-0 2022-02-1 (au cas oü qlq veux voir ceux du plantage bdd

[pnorman]

Given the age of the DB (>3 months) I recommend reimporting a fresh DB and restarting

[Marc-marc-marc]

même après libération d'un peu d'espace, la maj est toujours ko, j'ai désactivé le cron

@pnorman indeed, I'm looking to switch to another db on the same site

[Marc-marc-marc]

• déplacement osm2pqsql dans /data/project/osm2pqsql (le répertoire existait deja mais était vide)
• téléchargement dernier planet
• réimport en cours
• tester et réactiver les crons

[Marc-marc-marc]

import toujours en cours

j'ai connnecté hdm à la bdd osm25
Apr 19 22:03:24 hdm-tiles renderd[361134]: DEBUG: DONE TILE hot 18 82168-82175 117496-117503 in 52.559 seconds
cela refonctionne donc pour :

• les tuiles manquantes
• les tuiles déjà marquée comme dirty

il n'y a pas d'expiration de nouvelle tuile pour le moment avec la bdd de secours

[vinber]

est-ce qu'il manque quelque chose pour que ce rendu fonctionne mieux ?

c'est du matos, du temps, un mélange de tout cela ?

[Marc-marc-marc]

• import terminé
• index manquant dans le script créé à partir de l'historique des commandes
• en cours : maj de la bdd : le pbf importé ne date pas d'aujourd'hui, il faut résorber le lag
• j'ai constaté que l'espace disque a été divisé par 4, à voir si c'est pertinent alors qu'il y a qlq To de libre sur le serveur
• faire les PR (proposition d'amélioration des scripts) avec les soucis détecté
• il y a d'autres tickets à propos de la diversité des configs, ce qui fait qu'un bug résolu sur un serveur ne profite pas aux autres

[Marc-marc-marc]

j'ai regroupé dans le premier message ce que j'ai fais et ce qui reste à faire

[cquest]

J'ai invalidé les tuiles du cache et mis à jour les niveaux 0 à 12.
Petit test et comme tout semble bon, suppression de la redirection pour remettre le rendu en ligne.

apt update/dist-upgrade fait au passage, on est maintenant en renderd 0.6.1 et mapnik 3.1

J'ai laissé en Ubuntu 20.04 Focal car mod_tile/renderd ne sont pas dispo sur le PPA osmadmins en 22.04

[cquest]

l'espace disque pour les tuiles a été fortement réduit divisé par 4, à voir si c'est toujours pertinent alors qu'il y a qlq To de libre sur le serveur

Je ne vois aucune trace dans l'historique ZFS de changement du quota du cache de tuiles.

On peut effectivement le monter vu qu'il reste largement de l'espace sur le SSD. Je l'ai donc passé à 1To.

[cquest]

Les graphes munin ne se mettaient plus à jour, donc pas de rouge dans le tableau d'alarme.
C'est l'IPv6 qui ne routait plus.

Y aurait-il un moyen pour détecter les host/vm injoignables par munin et les remonter d'une façon ou d'une autre en alarme ?

[cquest]

Pour que les expire_list ne saturent pas le stockage, ajout en crontab root sur osm188 de :
find /data/work/osm2pgsql/expire_list/ -mtime +60 -delete

[Marc-marc-marc]

rendu humanitaire : lag de réplication du au réimport résorbé, je relance la génération des premiers niveaux pour les avoir avec des données à jour