script suppression de tuiles en cas d'espace disque faible

[Marc-marc-marc]

J'ai regardé le code qu'on utilisé pour hot et osm-fr il m'a l'air améliorable. le principal problème étant qu'on efface des tuiles mêmes si on n'a pas besoin d'espace disque. a titre de comparaison voici ce qui est utilisé pour osm.org https://github.com/openstreetmap/chef/blob/master/cookbooks/tile/templates/default/cleanup-tiles.erb ce script a un défaut : il traite toutes les niveaux sans différence, ce qui provoque parfois l'effacement de tuiles z10 puis leur création forcé par render_list problème contournable en créant un répertoire genre zoom-level-to-purge et en y mettant les niveau de zoom à traiter ping @cquest @ybon @MaelREBOUX pour avis

[alkino]

On peut voir le script ?

[cquest]

Je fais le ménage simplement à l'aide de find, avec des règles différentes par niveau.

echo `date +%H:%M:%S`' Delete old hot tiles in cache'
sudo find /var/lib/mod_tile/hot/15         -name *.meta -atime +90 -delete
sudo find /var/lib/mod_tile/hot/{16..17}   -name *.meta -atime +30 -delete
sudo find /var/lib/mod_tile/hot/{18..20}   -name *.meta -atime +15 -delete
echo `date +%H:%M:%S`' Delete old qa tiles in cache'
sudo find /var/lib/mod_tile/qa/{13..20}    -name *.meta -atime +2 -delete

C'est du cousu main... et ça marche bien depuis des années ;)

Les zooms précalculés ne sont jamais "nettoyés" et ceux qui prennent du temps à calculer (12-14) non plus, mais ils n'occupent pas tant d'espace disque.

Pour le reste, à chaque niveau de zoom ça ne supprime que les tuiles non consultées (atime) depuis un certain temps, décroissant avec le zoom. Conserver des tuiles obsolètes a un impact pendant les mises à jour de la base, car il faut les invalider et ça prend un peu de temps (pas trop sur SSD, bien plus sur HDD...)

Sur osm13, le SSD contenant le cache de metatuiles est ainsi occupé à environ 85-90% de façon très stable.

C'est /ssd sur http://munin.openstreetmap.fr/openstreetmap.fr/osm13.openstreetmap.fr/df.html

PS: Je préfère un bash en cron qu'un script ruby illisible... qui semble appeler "find" ;)

[Marc-marc-marc]

je suis surpris qu'invalider des tuiles non utilisée prennent beaucoup de temps. s'il y a une maj de la tuile, c'est une rare maj de la feuille de style ou c'est que quelqu'un a édité la zone, donc à souvent vu la zone, donc la tuile a souvent été utilisée récemment. il y a des stats du nombre de tuile veille touchée par une maj des données ? ne peux-t-on pas supprimer une veille tuile lorsqu'elle est invalide au lieu de le faire quand elle est encore valide ?

ça marche bien depuis des années ;)

le / d'osm25-201 étant à 100%, il est plus exact de dire "tu ne vois pas quand cela bug" :-)

indépendamment de l'importance de la lisibilité du code (je partage ton avis), le défaut de se limiter à 4 find c'est que rien ne dit que t'avais besoin de place quand ils ont été lancé et rien ne garanti qu'ils ont libéré assez de place après avoir été lancé. c'est de la pifométrie à ajuster régulièrement, ce qui contribue à la divergence des différents serveurs de rendu entre eux.

[cquest]

Le / d'osm25 à 100% n'a pas de rapport avec les tuiles qui n'y sont pas stockées. Je regarde pourquoi il est plein.

[Marc-marc-marc]

je ne parle pas d'osm25 mais du rootfs du conteneur 201 /var/lib/lxc/201/rootfs, même si l'un impacte l'autre http://munin.openstreetmap.fr/openstreetmap.fr/osm25.openstreetmap.fr/df.html mais en effet je me suis fait avoir parce que les tuiles sont dans /data/osm2pgsql ce qui n'était pas trivial vu le nom du point de montage et pour compliquer le tout, certains tuiles sont dans /var/lib/mod_tile/osmfr qui lui est bien dans le fs /

[cquest]

Euh, oui, je parlais de ça moi aussi (message parti trop rapidement).

Il semblerait que j'ai oublié un truc lors de l'install d'osm25... le script le suppression des vieilles tuiles (ou alors je l'ai bien planque ce coquin).

En train d'élaguer...