Re: [OSM-dev-fr] Tunning de postgresql pour des bases osmosis et/ou osm2pgsql
Salut, un rendu tango ... Moi c'est plutôt salsa, et ça rend bien aussi ;-) késako ? Question renderd en pointe je plafone à 15 tuiles (tous les zoom confondu) par min. 15/minute c'est quand même plutôt faible je trouve, y'a peut-être bien un problème quelque part. Moi qui utilise un traitement archaïque en lieu et place de rendered, avec un style type map...@osm.org plus des courbes de niveau (ce qui prend pour ainsi dire autant de temps, voir plus à fort zoom) je viens de faire un test, et à zoom 14, pour rendre des tuiles de ce type : http://minilien.fr/a0mxys J'arrive à un résultat de ~20 tuiles/s (pour les zoom 17/18 où il n'y a quasiment rien à afficher et quasiment rien à récupérer de la base, ça va encore plus vite : ~100 tuiles/s) Pour les tuiles de zoom 11, qui chez moi prennent le plus de temps, ça tombe à ~5t/s Pour debugger ce genre de cas, j'utilise nik2img.py (qui permet de ne tester que la partie postgres+mapnik) et j'ai mon test case qui est le suivant : time ./nik2img.py -m style.xml -i png -o image.png -s 1000,1000 -e 5.9,45.55,5.95,45.59 style.xml mon style mapnik à tester ça génère une image de la ville de chambéry, et chez moi, ça prend 1.25s pour un style proche de celui de map...@osm.org -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Tunning de postgresql pour des bases osmosis et/ou osm2pgsql
15 tuiles ou 15 meta-tuiles? -- Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté. sly (sylvain letuffe) li...@letuffe.org a écrit : Salut, un rendu tango ... Moi c'est plutôt salsa, et ça rend bien aussi ;-) késako ? Question renderd en pointe je plafone à 15 tuiles (tous les zoom confondu) par min. 15/minute c'est quand même plutôt faible je trouve, y'a peut-être bien un problème quelque part. Moi qui utilise un traitement archaïque en lieu et place de rendered, avec un style type map...@osm.org plus des courbes de niveau (ce qui prend pour ainsi dire autant de temps, voir plus à fort zoom) je viens de faire un test, et à zoom 14, pour rendre des tuiles de ce type : http://minilien.fr/a0mxys J'arrive à un résultat de ~20 tuiles/s (pour les zoom 17/18 où il n'y a quasiment rien à afficher et quasiment rien à récupérer de la base, ça va encore plus vite : ~100 tuiles/s) Pour les tuiles de zoom 11, qui chez moi prennent le plus de temps, ça tombe à ~5t/s Pour debugger ce genre de cas, j'utilise nik2img.py (qui permet de ne tester que la partie postgres+mapnik) et j'ai mon test case qui est le suivant : time ./nik2img.py -m style.xml -i png -o image.png -s 1000,1000 -e 5.9,45.55,5.95,45.59 style.xml mon style mapnik à tester ça génère une image de la ville de chambéry, et chez moi, ça prend 1.25s pour un style proche de celui de map...@osm.org -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org _ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Tunning de postgresql pour des bases osmosis et/ou osm2pgsql
sly (sylvain letuffe) a écrit on 13/12/2011 10:46: Salut, un rendu tango ... Moi c'est plutôt salsa, et ça rend bien aussi ;-) késako ? Question renderd en pointe je plafone à 15 tuiles (tous les zoom confondu) par min. 15/minute c'est quand même plutôt faible je trouve, y'a peut-être bien un problème quelque part. Moi qui utilise un traitement archaïque en lieu et place de rendered, avec un style type map...@osm.org plus des courbes de niveau (ce qui prend pour ainsi dire autant de temps, voir plus à fort zoom) je viens de faire un test, et à zoom 14, pour rendre des tuiles de ce type : http://minilien.fr/a0mxys J'arrive à un résultat de ~20 tuiles/s (pour les zoom 17/18 où il n'y a quasiment rien à afficher et quasiment rien à récupérer de la base, ça va encore plus vite : ~100 tuiles/s) Pour les tuiles de zoom 11, qui chez moi prennent le plus de temps, ça tombe à ~5t/s Pour debugger ce genre de cas, j'utilise nik2img.py (qui permet de ne tester que la partie postgres+mapnik) et j'ai mon test case qui est le suivant : time ./nik2img.py -m style.xml -i png -o image.png -s 1000,1000 -e 5.9,45.55,5.95,45.59 style.xml mon style mapnik à tester ça génère une image de la ville de chambéry, et chez moi, ça prend 1.25s pour un style proche de celui de map...@osm.org On est tous d'accord j'imagine pour dire qu'il est impossible de comparer si on a pas le même volume de données et le même style, des requêtes SQL différents ne donneront pas les même résultats :). De mon coté il faut que je fasse des mesures, mais la piste d'optimisation sur laquelle je travaille et d'organiser la table sur disque suivant l'index spatial avec la commande CLUSTER http://www.postgresql.org/docs/8.4/static/sql-cluster.html Le plus gros de l'optim pour moi reste au niveau des index quand le rendu est fait avec des données dans Postgis, et surtout au niveau des caches ensuite pour tous les autres cas, mapnik, tilecache, geoserver. A++ -- Rodolphe Quiédeville http://cartosm.eu - Intégration de carte libre sur site web Blog : http://blog.rodolphe.quiedeville.org/ SIP/XMPP : rodol...@quiedeville.org ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Tunning de postgresql pour des bases osmosis et/ou osm2pgsql
Le 13/12/2011 11:13, Yves a écrit : 15 tuiles ou 15 meta-tuiles? méta-tuiles ... c'est munin qui parle pour renderd :-) -- Thomas Clavier http://www.tcweb.org Jabber/XMPP/MSN/Gtalk :t...@jabber.tcweb.org +33 (0)6 20 81 81 30 +33 (0)950 783 783 signature.asc Description: OpenPGP digital signature ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Tunning de postgresql pour des bases osmosis et/ou osm2pgsql
Pour info, un message sur la liste Maps-I (Wikimedia), concernant les performances de rendus sur le ToolServer : http://lists.wikimedia.org/pipermail/maps-l/2011-December/001065.html Avec des idées concernant les schémas de base (faire le tri dans les polygones pour les niveaux de zoom faibles, et en particulier virer la myriade de batiments) et aussi les feuilles de style, pour limiter les accès aux bases autant que possible Le 13 décembre 2011 17:41, Thomas Clavier t...@tcweb.org a écrit : Le 13/12/2011 11:13, Yves a écrit : 15 tuiles ou 15 meta-tuiles? méta-tuiles ... c'est munin qui parle pour renderd :-) -- Thomas Clavier http://www.tcweb.org Jabber/XMPP/MSN/Gtalk :t...@jabber.tcweb.org +33 (0)6 20 81 81 30 +33 (0)950 783 783 ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Tunning de postgresql pour des bases osmosis et/ou osm2pgsql
Le 09/12/2011 12:19, sly (sylvain letuffe) a écrit : Tu as quelques stats de ton nombre de tuile générées par minutes ou secondes ? Tu as combien de visiteurs sur ton service de tuiles ? J'ai dû oublié, mais tu as quoi comme rendus ? un rendu tango ... j'ai pas encore rebranché le rendu beciklo :-( Question renderd en pointe je plafone à 15 tuiles (tous les zoom confondu) par min. Question trafic, j'ai quasiment pas de visteurs ... en moyenne 8 connections simultanées aux heures de pointe :-) -- Thomas Clavier http://www.tcweb.org Jabber/XMPP/MSN/Gtalk :t...@jabber.tcweb.org +33 (0)6 20 81 81 30 +33 (0)950 783 783 signature.asc Description: OpenPGP digital signature ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Tunning de postgresql pour des bases osmosis et/ou osm2pgsql
Le 09/12/2011 11:30, sly (sylvain letuffe) a écrit : Plus sérieusement, tous les paramètres que j'ai tuné sur postgresql n'ont en général joués (de manière visible) que sur l'import initial ou les minutes diff, les requêtes de lecture de la base sont elles toujours à peu près au même niveau (sauf si j'ai fais sauter un index mais là, ça se voit tout de suite), c'est donc en amont qu'il faut améliorer. on est d'accord, mon problème c'est le temps de génération des tuiles. L'import est long mais une fois qu'il est fait ça roule tout seul. - Ne générer que ce qui est utile (vérifier la gestion de cache des tuiles, étude d'utilisation par les utilisateurs) mod_tile fait ça pas mal :-) D'ailleurs pour ceux qui veulent la dernière version pour debian, mon jenkins met à disposition les paquets debian mod_tile et rendred pour squeeze ici : deb http://repository.azae.net/debian/squeeze/ squeeze main Pour les autres distrib, faut que je trouve le temps de corriger le job :-) - Matériel : type de disque et arrangement raid (pour booster le nombre d'io/s possibles) c'est là mon problème, j'ai 2 disques SATA2 en raid 0 et je ne peux pas les changer pour du SSD ... -- Thomas Clavier http://www.tcweb.org Jabber/XMPP/MSN/Gtalk :t...@jabber.tcweb.org +33 (0)6 20 81 81 30 +33 (0)950 783 783 signature.asc Description: OpenPGP digital signature ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Tunning de postgresql pour des bases osmosis et/ou osm2pgsql
sly (sylvain letuffe) a écrit on 05/12/2011 15:19: autovacuum = off D'où vient ce autovacuum = off ? C'est déconseillé dans les documentations récentes de postgresql. Qu'est-ce-qui le justifie ? Justification : pour aller encore plus vite Contraintes : l'espace disque augmente encore plus vite que la taille OSM à cause des trous dans la structure de fichier postgresql lors des suppressions. Je viens de le remettre chez moi pour voir si c'est pénalisant, sinon, il y'a la solution de lancer un VACUUM manuel de temps en temps (au moment où la machine est plus tranquille) pour purger ces trous A propos de VACUMM le vacuum full est désormais déconseillé à partir de le 9.0 http://wiki.postgresql.org/wiki/VACUUM_FULL A++ -- Rodolphe Quiédeville http://cartosm.eu - Intégration de carte libre sur site web Blog : http://blog.rodolphe.quiedeville.org/ SIP/XMPP : rodol...@quiedeville.org ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Tunning de postgresql pour des bases osmosis et/ou osm2pgsql
On vendredi 2 décembre 2011, Thomas Clavier wrote: Jocelyn, sly, ya moyen d'avoir vos astuces de tunning postgres ? http://osm.tcweb.org en aurais bien besoins :-) Puis-je proposer de continuer la discussion sur la liste dev-fr (en copie) ? Un bon tutoriel : http://weait.com/content/build-your-own-openstreetmap-server dans postgresql.conf : shared_buffers = 128MB # 16384 for 8.1 and earlier checkpoint_segments = 20 maintenance_work_mem = 256MB # 256000 for 8.1 and earlier autovacuum = off Auquel j'ai appris qu'il faut rajouter : http://lists.openstreetmap.org/pipermail/dev/2011-December/023849.html fsync = off synchronous_commit = off (Import plus rapide au détriment de la sécurité des données en cas de crash serveur au mauvais moment) Après, il faut sans doute que tu nous disent ce qui ne va pas sur ton serveur, d'autres problème peuvent se rajouter, un petit mot sur ta config et les commandes que tu lances pourrait aider. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
