J’ai profité de l’été pour me (re)-lancer dans le chantier “serveurs de tuiles”.
Petits rappels
OpenStreetMap France héberge génère plusieurs fonds de carte à l’aide de ses “serveurs de tuiles”:
-
rendu “FR”, une adaptation commencé en 2012 du style OSM de l’époque, destinée à un public francophones (noms en français en priorité, icône plus parlantes en France, etc) avec des ajouts originaux (terrains de sport, etc)
-
le rendu “humanitaire” largement utilisé par HOT et disponible aussi sur openstreetmap.org
-
le rendu “CyclOSM” , le petit dernier, lui aussi disponible sur openstreetmap.fr
À cela s’ajoute aussi OpenRiverBoat, un rendu adapté à la navigation fluviale, des rendus en langues régionales, des rendus techniques.
Les trois premiers sont assez fortement utilisés et complexes. Le rendu “FR” contient par exemple 82 couches différentes parfois multiples ce qui donne au total plus de 170 couches de dessin pour arriver au rendu final avec plus de 10000 règles qui servent à décider comment représenter graphiquement tel ou tel objet.
Les outils utilisés
Le cœur est une base postgresql/postgis, qui contient les données OSM utiles à la fabrication du fond de carte et à sa mise propre mise à jour.
Les données OpenStreetMap brutes sont importées dans postgresql puis mises à jour régulièrement à l’aide d’osm2pgsql. Typiquement la base résultat occupe environ 1To.
La génération du fond de carte est faite par renderd qui utilise la librairie mapnik pour transformer les données vectorielles issues de postgresql en images en appliquant une feuille de style.
Cette feuille de style au format XML utilisée par mapnik, est générée à l’aide de kosmtik à partir un code source écrit en cartocss, une sorte de CSS adaptée à la cartographie.
renderd interagit avec apache via mod_tile qui gère un cache de “méta-tuiles” contenant 8x8 tuiles telles que demandées par les navigateurs, de 256 ou 512 pixels de côté (version “retina” en double résolution).
Un cache est en effet nécessaire car le calcul d’une méta-tuile peut prendre plusieurs secondes (parfois plusieurs dizaines de secondes).
Besoin grandissants et saturation
Depuis plusieurs années, nos serveurs de tuiles saturent régulièrement et ont du mal à suivre les demandes pour mettre à jour le fond de carte sans trop de délais.
En effet, la base de données OpenStreetMap est en perpétuelle évolution, et le fond de carte produit avec a besoin d’être mis à jour en permanence, surtout quand ceux-ci sont consultés par des contributeurs qui veulent vérifier que leurs contributions ont bien été prises en compte et sont correctes.
Lors de chaque mise à jour faite par osm2pgsql, une liste des tuiles impactées par les changements et générée, or, le nombre de contribution augmente au rythme du nombre de contributeur qui de fait que croître (tant mieux !).
La quantité de données dans la base de données augmente elle-aussi, ce qui fait plus d’objets à récupérer dans la base de données et à dessiner sur une zone donnée.
Et troisième phénomène, les consultations elles aussi ont fortement augmenté… donc tout mis bout à bout, la charge sur les serveurs n’est plus du tout la même que lorsque nous les avons mis en place il y a bientôt 10 ans pour certains !
L’ajout de RAM ou de SSD toujours plus rapides et volumineux ne suffit plus… il faut changer aussi les serveurs.
Tests et optimisations
Revoir la stratégie de mise à jour du cache
À chaque contribution, à un endroit donné, toutes les tuiles sont potentiellement impactée à tous les niveaux. osm2pgsql ne sait pas en effet déterminer si tel objet figure bien sur le rendu niveau de zoom par niveau de zoom.
L’ajout ou la modification d’un banc qui ne sera visible que sur les plus forts zoom, n’a pas d’impact sur les zooms plus faibles… mais c’est très complexe à déterminer.
Recalculer une tuile de niveau 13 ou 14 est bien plus coûteux car elles contiennent typiquement plus d’objets que les tuiles de zoom 19 ou 20. Sur Paris par exemple, c’est de l’ordre de 100 000 objets en zoom 13/14 contre quelques milliers en zoom 19/20.
Il faut donc limiter le recalcul coûteux et souvent inutile à certains zoom.
Pour les zoom 0 à 12, ce recalcul est fait une fois par semaine, en plein nuit, pendant les heures creuses (qui étaient bien rares).
Jusqu’à maintenant, à chaque mise à jour de la base, toutes les tuiles à partir du zoom 13 était “invalidéee”, c’est à dire marquées dans le cache comme obsolètes et devant être recalculées. Dès qu’elles étaient demandées pour être vue par un internaute, mod_tile demandait à renderd de la recalculer
J’ai remplacé cette invalidation systématique, par une invalidation zoom par zoom. Le zoom 13 est (au moment ou j’écris ce billet) invalidé une fois par jour, puis le 14 deux fois par jour, le 15 et le 16 quatre fois par jour, mais pas en même temps, et à partir du 17 il n’y a pas de changement. Cela va sûrement évoluer.
Un pic de charge est visible sur les graphes du serveur suite à l’invalidation, mais tout cela reste assez lissé pour éviter les saturations tout en favorisant le recalcul des zooms les plus élevés, là où un contributeur voudra vérifier sa contribution.
Nouveaux serveurs
Cela faisait longtemps qu’on devait le faire suite à un appel aux dons de fin 2018 et un nouveau serveur a été acheté cet été. Une machine d’occasion, donc à prix très raisonnable comparé à du neuf, mais d’une génération pas trop ancienne.
Il s’agit d’un rack Fujitsu Primergy CX400M1, contenant 4 lames avec chacune 2 Xeon avec 12 cœurs… 96 cœurs au total !
Voici une des lames, avec à gauche un premier CPU avec sa RAM, puis le second, puis les 2 emplacements PI Express 3.0:
Ajout de RAM (256Go, mais chaque lame peut avoir jusqu’à 1To de RAM) de SSD NVMe et SATA (2To chacun)… et on peut démarrer les tests.
ZFS or not ZFS ?
ZFS est un système de stockage très complet, qui aligne plein de fonctionnalités intéressantes. J’ai voulu vérifier que ceci ne se faisait pas (trop) au détriment de la performance…
J’ai donc testé l’import de la base monde (alias “planet”) en ZFS, avec et sans compression, avec de petits blocs de 8K ou des gros de 128Ko, etc… au final ça ne change presque rien, mais l’espace occupé sur disque par la base de données peut être divisé par 2 !
Ceci a aussi pour conséquence qu’une part plus importante de la base peut reste en RAM dans le cache de ZFS (l’ARC) qui reste compressé lui aussi… et donc on limite encore un peu plus les I/O en utilisant un peu de CPU pour la décompression à la volée… et avec 24 cœurs il y a de quoi faire :)
ZFS validé !
Tuning de postgresql
Postgresql et postgis ont eux aussi évolué (versions respectives 13 et 3.1)… de nouveaux types d’index sont venus compléter les index GIST, il s’agit des SP-GIST.
Passer de GIST à SP-GIST permet de diviser par 3 la taille des index sur les objets linéaires et surfaciques, un peu moins sur les ponctuels.
Des index plus petits, c’est plus d’index en cache, et là encore plus de performances au final.
Un autre progrès vient d’osm2pgsql qui utilise un nouvel index bien plus compact pour retrouver les way passant par un node.
Couplé à la compression de ZFS, c’est au final près de la moitié de la base de données (data+index) qui peut tenir désormais dans les 256Go de RAM du serveur ce qui accélèrent grandement les requêtes en évitant les accès au SSD qui bien que rapide est quand même bien plus lent que la RAM.
Tuning de renderd/mapnik
Là cela se passe à plusieurs niveaux :
-
simplifier la feuille de style, par exemple en réduisant le nombre de “couches”
-
améliorer les requêtes postgresql pour retourner uniquement les données utiles afin de réduire tous les traitements en aval
-
bien exploiter les index de postgresql
-
optimiser les appels de mapnik à postgresql
J’avais déjà passé mon été dernier sur les 3 premiers points, cette fois-ci j’ai attaqué le 4ème et là grande surprise !
cache CACHE !
Certaines couches de dessin utilisent les mêmes données, c’est à dire qu’une seule requête est faite dans la base de données mais qu’on applique ensuite plusieurs passe de style dessus.
Le fonctionnement pas défaut de mapnik est étonnant… il ré-exécute la requête.
Une option (cache-features) permet de conserver le résultat et de ne pas répéter la requête plusieurs fois, mais ce n’est pas le fonctionnement pas défaut !
Là, je comprends enfin quelque chose… un “problème” constaté depuis plusieurs années que je n’expliquait pas: une perte énorme de performance. En fait mapnik, a sûrement changé son mode par défaut (je n’ai pas vérifié)… sans trop prévenir.
L’ajout de cette simple option a eu un effet radical sur notre serveur osm25 qui s’occupe essentiellement du rendu “FR”:
-
53% des tuiles retournées par le serveur étaient expirées, c’est à dire non mises à jour, c’est maintenant moins de 4%
-
le CPU utilisé a très fortement baissé
-
le nombre de tuiles calculées par seconde a été multiplié par 4
C’est comme si on avait retiré le frein à main :)
D’autres améliorations ont aussi été faites en lisant mieux la documentation du fonctionnement de mapnik avec postgresql, comme l’utilisation de curseurs. J’avais loupé cette évolution, car on n’a pas toujours le temps de lire en détail les nouveautés lors des mises à jour de nos outils… un tort !
La suite…
Il reste à finaliser des modifications de la feuille de style “FR”, pour la déployer sur le nouveau serveur.
En attendant, la version en développement est visible ici:
https://osm.cquest.org/dev/#14/48.8500/2.3500
Harmoniser les index utiles aux 3 principaux rendus sera aussi un chantier à faire, c’est déjà largement le cas entre le rendu FR et humanitaire.
OpenStreetMap
OpenStreetMap au 1er Janvier 2007
Encore quelques noeuds issus de PGS 2006
Exemple de route décalée