osm-fr
osm13 osm165 (postgresql base mondiale) : fichiers expire_liste jamais purgé
les données des tuiles à expirer ne semblent être jamais purgée même après usage sans erreur et ce jusqu'à saturation donc plantage du service ! osm165 pas de cron spécifique, le script osm2pgsql n'efface que s'il a un style a traiter (ce qui n'est actuellement pas le cas sur osm165, cette partie là est sur osm166) osm166 accès qu'en lecture p'tre la cause de #169
- [x] solution temporaire find rm quotidien mis en place le 8 juin sur osm165 et le 26 juin sur osm13
- [x] documenter s'il y a une raison de conserver expire_list après utilisation sans erreur par tous les rendus concernés (la seule constatée est "c'est comme cela sur osm25 donc à faire partout" auquel on peux opposer "faire autrement pour résoudre le problème énoncé")
- [ ] s'il n'y a aucune raison valable, alors pas besoin de les garder et modifier le design en conséquence (si cela semble impossible, je m'en chargerai)
- [ ] s'il y a une raison valable, ajouter une option dans un fichier de configuration, afin de pouvoir à l'avenir partager le même code sur les 6 serveurs de rendus, modifier la logique pour réduire les io de la boucle par un facteur de 2000
- [ ] même chose pour la conservation en cas d'erreur, et idéalement la notification qui devrait l'accompagner
- [ ] virer la solution temporaire renseignée ci-dessus
j'ai purgé tout sauf le jour courant, on est retombé à 11% d'espace disque sur / Le graphe df osm165/osm166 est étrange : très lente montée comme s'il n'y avait jamais de rm puis montée bcp plus forte depuis 3j comme si qlq chose avait changé. le cron@osm165 a été modifié le 28, hélas on ne garde pas d'historique
fix temporaire : ajout cron@osm165
0 * * * * chronic find /data/work/osm2pgsql/expire_list/ -name expire.list-* -type f -mtime +1 -ls -delete
Tu peux garder un peu plus que 24.h.. un mois c'est pas énorme et si un serveur de tuiles "secondaire" est coupé il peut se resynchroniser pendant 1 mois.
Je vois par contre des upgrades chaque minute... c'est indispensable ?
EDIT: c'est la conception même qui est non optimale :
-
situation actuelle : remplir un répertoire avec des expire_list comprimé et laissant chaque rendu parcourir la liste sans arrêt afin de trouver l'unique qui doit être traité et le décomprimer : sur osm166, cela prend 1/5 des io et pourri/invalide le cache disque. sur osm13, teslix a aussi constaté une invalidation du casque disque importante. ensuite il faut deviner quand le fichier n'est plus nécessaire (environ la min quand tout va bien <> garder "la durée d'une panne")
-
suggestion : faire l'inverse (plus proche de ce qui est fait sur osm13 actuellement) : quand il y a un diff, on fait l'expire des différents style puis on l'efface. si on est en erreur on peux éventuellement le garder et le compresser au cas où qlq voudrait le voir ou pour l'utiliser à la reprise de la pane. si on a x tentatives en erreur, on s'arrête, aucun sens de faire d'accumuler des Go en "erreur", cela risque d'empirer les choses. ne pas comprimer avant usage mais après, cela fait gagner une décompression par style
les updates à la minute ont été mis en place suite à l'expérience des oom sur osm25 causé par une expire_list trop grande en une fois (l'autre solution est de réduire le zoom max et d'expirer plus approximativement, donc encore plus de tuile à regénérer même si elles n'ont pas subie de modif). vu que osm25 a la file pleine, ce n'est actuelement pas une alternative interessante (en plus de l'impact utilisateur et du fait que je doute fortement que générer + de tuiles compense les io liés à un expire_list plus précis)
Je reprends l'essentiel de ce que j'ai expliqué sur irc...
osm2pgsql produit une liste de tuiles impactés par chaque cycle d'update. On peut limiter les zoom sur lesquels cette liste est produite. Le premier zoom doit être celui non généré en batch, le dernier le zoom max du style - 3 (à cause des metatuiles de 8x8 soit 2^3), 17 maxi pour nous. Ce processus a besoin de RAM et ça augmente exponentiellement (x4) avec chaque niveau de zoom, donc zoom 20 peut expliquer des OOM en fin d'osm2pgsql. Passer de zoom 17 à 20 multiplie aussi par 10 la taille des fichiers d'expiration.
Pourquoi les conserver ? Sur osm25, la bdd est utilisé par 2 containers de rendu (201 et 202). Si l'un d'eux supprime le fichier après traitement, l'autre ne l'aura pas forcément traité. Sur osm13, tout le cycle (update / expiration) est local, pas besoin de garder les fichiers. osm165/osm166 fonctionne comme osm25/osm201.
Combien de temps les conserver ? Si un container de rendu prends du retard ou est en panne ou en pause, s'il n'applique pas chaque liste d'expiration, on ne sait plus quelles tuiles du cache sont bonne ou pas, il faut potentiellement tout régénérer :( Donc conserver pendant quelques jours ou semaines est utile et ne prends pas trop d'espace.
Le nombre de fichiers d'expiration ? Les updates n'ont pas besoin d'être à la minute. On a longtemps fonctionné à 5mn, ce qui est déjà très court et après tests avait été jugé minimal. Des updates plus fréquents ont tendance à invalider à plusieurs reprises en peu de temps les même tuiles car les éditions se font souvent pas petits changeset locaux (surtout avec iD).
L'impact sur les I/O Ces fichiers (en zoom 17 maxi) ne sont pas énormes, les IO pour leur compression gzip sont limités (vu qu'il sont réduits par la compression). L'impact principal est dans leur traitement par render_expire qui pour chaque ligne, va tester la présence de la metatile dans le filesystem, et modifier sa date si elle existe. Sur osm13, les tuiles étaient stockées sur HDD, on a migré sur le SSD pour ça, car aucun moyen n'a été trouvé pour une amélioration de render_expire sur ce plan.
Je propose donc:
- [ ] configurer osm2pgsql pour ne pas produire la liste au delà du zoom 17 (comme sur osm13 et osm25)
- [x] réduire la fréquence d'update à 5mn
- [ ] find/delete des fichiers d'expiration sur une durée à déterminer
- [ ] basculer les caches de tuiles d'osm166 sur ssd-sata
L'un de nous 2 dois être fatigué ou dogmatique car ce que tu dis n'a aucun sens (tu altères ma question) ou est totalement hors sujet (ta réponse est sans lien avec le problème exposé) je propose donc de revenir à un ticket = un sujet pour être lisible et répondre au problème exposé. cela permet aussi de faire des tâches indépendantes, lisibles, agiles J'ai extrait les 2 hors sujet en ticket séparé. j'ai édité le premier sujet pour mettre la todo liste en rapport avec ce sujet.