[OSM-dev-fr] Optimization base postgis pour tuiles mapnik

[sly (sylvain letuffe)]

On mardi 19 janvier 2016, Marc Ducobu wrote:
> J'utilise render_list pour précalculer les tuiles. Est-ce la bonne
> méthode ? 

Oui

> Est-ce que ça vaut le coût de générer les tuiles de 12 à 15 ?

Oui car ça sera plus fluide d'utilisation pour tes utilisateurs qui n'auront 
pas à attendre trop leur chargement, mais le zoom 15 va te prendre des plombes 
de temps sur l'europe !
Mais zoom 12,13 je répond oui sans trop d'hésitation, 14 à tester, et 15 ça va 
être long.
Se posant alors la question de la ré-génération. Qu'as tu prévu quand OSM sera 
mis à jour ?

> Pour le SSD je me suis planté... J'ai sous-estimé l'avantage du SSD. Y a
> t il une stratégie à privilégier quand on n'a pas le SSD ?

Oui, rendre le serveur à OVH et en reprendre un avec SSD (ça te coûtera 50 
euros soit un mois, à mon avis, ça les vaut) si tu as bien sauvegarder toutes 
tes configs, tu ne devrais pas en avoir pour long de refaire


> 
> On 18/01/16 11:22, Christian Quest wrote:
> > Pour info, sur tile.openstreetmap.fr <http://tile.openstreetmap.fr>
> > plusieurs styles sont générés et les principaux sont le style HOT et le
> > style FR.
> > 
> > Pour ces deux styles, les tuiles des zooms 1 à 11 sont précalculés et
> > mis à jour une fois par semaine seulement. Certaines metatiles peuvent
> > prendre 30mn à être calculées (2 en zoom 9 centrées sur
> > France/Allemagne).
> > 
> > Autre chose... pourquoi un serveur avec 8To de disques rotatifs ?
> > j'aurai plutôt pris un EG32 avec 2x480Go de SSD pour juste 5 euros de
> > plus. Pour ce type d'usage, le SSD apporte un énorme gain de perf.
> > 
> > 
> > Le 16 janvier 2016 à 19:19, Frédéric Rodrigo <fred.rodrigo at gmail.com
> > 
> > <mailto:fred.rodrigo at gmail.com>> a écrit :
> >     Ça prend du temps c'est normal.
> >     La réponse est : il faut utiliser un cache.
> >     
> >     Ces tuiles sont très couteuse à calculer et contienne peu souvent
> >     des mises à jour visible.
> >     Ce qui se pratique même est de les précalculer pour ne pas que
> >     l'utilisateur ai à attendre.
> >     
> >     Le 15/01/2016 16:03, Marc Ducobu a écrit :
> >         Bonjour,
> >         
> >         La couverture de la DB est européenne.
> >         
> >         Je cherche à installer un serveur de tuiles sur l'europe. Le
> >         serveur utilisé est un EG-32 d'ovh (
> >         
> >           - CPU : Intel Xeon E5-1620v2 4c/8t 3,7 GHz/3,9 GHz
> >           - RAM : 32 Go DDR3 ECC 1600 MHz
> >           - Disques : 2x 4 To SATA3
> >         
> >         (https://www.ovh.com/fr/serveurs_dedies/infra/2014-EG-32.xml)).
> >         Tout est
> >         installé mais il y a un problème : à un niveau de zoom haut, les
> >         tuiles
> >         mettent du temps à être générées. Et donc, lors d'un zoom, il
> >         faut pas
> >         mal de temps pour que les tuiles soient affichées.
> >         
> >         Du coup j'ai essayé de configurer la base postgresql afin
> >         d'optimiser
> >         son temps de réponse.
> >         
> >         Pour l'instant les variables que j'ai changées sont :
> >         effective_cache_size = 24GB
> >         wal_buffers  = 16MB # avant 4MB
> >         random_page_cost = 3 # avant 4
> >         fsync = off # avant on
> >         synchronous_commit = off # avant on
> >         maintenance_work_mem 4096 # avant 64MB
> >         work_mem =  500MB # avant 4MB
> >         
> >         (dans ce que j'ai lu ils parlent de modifier checkpoint_segment =
> >         à 1600. Comme celui actuel est de 3, ça me semble bcp et du coup
> >         j'hésite.)
> >         
> >         Ces changements n'ont pas amélioré le temps de génération des
> >         tuiles.
> >         
> >         Que pensez-vous de ces paramètres ? Aussi j'aimerai bien utiliser
> >         un outil afin de tester la manière dont réagit la génération de
> >         tuiles en
> >         fonction des paramètres. Avez-vous un outil / une méthode à
> >         conseiller ?
> >         
> >         Merci bcp.
> >         
> >         Marc
> >         
> >         _______________________________________________
> >         dev-fr mailing list
> >         dev-fr at openstreetmap.org <mailto:dev-fr at openstreetmap.org>
> >         https://lists.openstreetmap.org/listinfo/dev-fr
> >     
> >     _______________________________________________
> >     dev-fr mailing list
> >     dev-fr at openstreetmap.org <mailto:dev-fr at openstreetmap.org>
> >     https://lists.openstreetmap.org/listinfo/dev-fr


-- 
sly, direct contact : sylvain at letuffe.org
http://wiki.openstreetmap.org/wiki/User:Sletuffe
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/dev-fr/attachments/20160119/5abb7062/attachment-0001.html>