serveur de tuiles conseils paramétrage BDD PG

Extraire des données OSM, créer sa carte, uMap, utiliser sur un GPS ou un smartphone...
Niarolf
Messages : 16
Inscription : jeu. avr. 06, 2017 9:35 am
Localisation : Hauts de Seine

serveur de tuiles conseils paramétrage BDD PG

Message par Niarolf » sam. mai 06, 2017 8:16 pm

Bonjour à tous,
maintenant que j'ai tout installé et que j'ai des tuiles, je cherche à bien paramétrer le tout car j'ai des lenteurs côté BDD.
Donc question plutôt destinée à ceux qui travaillent sur des grosses infrastructures (serveurs OSM France par exemple)
Voici mon architecture car j'ai du dissocier la BDD et les rôles applicatifs sur des VM distinctes :
Tiers 2 :
- VMs avec le mod_tile
- VM pour les update des données et shapefiles
Tiers 3 :
- BDD PG 9.4 postgis 2.1 et hstore sur cluster Solaris (avec insertion des données planet)
Pour info 760GB de BDD prête en moins de 4 jours avec osm2pgsql (4 processes 16Go de cache au total)
J'ai de grosses lenteurs du côté des requêtes, qu'est-ce que vous avez sur vos BDD PG (postgresql.conf) ?
Merci pour vos conseils

yvecai
Messages : 56
Inscription : ven. févr. 26, 2016 4:49 pm

Re: serveur de tuiles conseils paramétrage BDD PG

Message par yvecai » dim. mai 07, 2017 8:46 am

Qu'appelles tu problèmes de lenteur ? Certaines tuiles aux zooms 0-13 peuvent prendre plusieurs minutes, c'est normal.

Niarolf
Messages : 16
Inscription : jeu. avr. 06, 2017 9:35 am
Localisation : Hauts de Seine

Re: serveur de tuiles conseils paramétrage BDD PG

Message par Niarolf » mer. mai 10, 2017 5:14 pm

Je parles de lenteurs quand j'ai des requêtes qui mettent plus de 20 secondes en temps d’exécution.

yvecai
Messages : 56
Inscription : ven. févr. 26, 2016 4:49 pm

Re: serveur de tuiles conseils paramétrage BDD PG

Message par yvecai » mer. mai 10, 2017 8:31 pm

Et je parle du niveau de zoom auquel tu effectue ces requêtes. :D
Selon, 20" c'est normal.

Avatar de l’utilisateur
cquest
Messages : 1934
Inscription : ven. avr. 16, 2010 12:22 am
Localisation : Val de Marne
Contact :

Re: serveur de tuiles conseils paramétrage BDD PG

Message par cquest » ven. mai 12, 2017 8:06 am

C'est quoi un cluster solaris pour postgres ?

4 jours pour importer une base (monde j'espère !) c'est TRES long et le signe de ressources hardware inadaptées...

Quelques détails sur cette config (hardware et software) postgres ?


Notre serveur de tuiles principal n'utilise aucune VM, pas de cluster... l'important est d'avoir des latences les plus faibles sur les I/O disque (et de la RAM pour éviter les I/O). La base postgres est sur un SSD Samsung 850 Pro (voir config d'osm13 sur https://wiki.openstreetmap.org/wiki/FR: ... #Dell_R610).

Postgres 9.6 serait aussi pas plus mal... inutile de prendre 2 versions de retard lors d'une install fraiche ;)

Niarolf
Messages : 16
Inscription : jeu. avr. 06, 2017 9:35 am
Localisation : Hauts de Seine

Re: serveur de tuiles conseils paramétrage BDD PG

Message par Niarolf » ven. mai 12, 2017 12:27 pm

Merci Christian pour ton retour,

Exact pour les 4 jours qui correspondent à l'insertion des données monde (mon ancien chef, Éric, m'a fait part que tu étais allé bien plus vite) et oui insertion effectuée sans trop de tunning ne connaissant pas trop le process osm2pgsql dans ses actions en BDD. (osm2pgsql mis avec 4 process avec 4Go de cache chacun)

Notre process m'oblige à dissocier les tâches sur des environnements distincts.

Un cluster solaris, c'est du matériel tournant sous unix (https://en.wikipedia.org/wiki/Solaris_Cluster) pour mutualiser les ressources pour les différentes bases (Oracle, PG ou MySQL) et gérer les bascules sur des sites distants en cas de panne. Pour les disques de la BDD c'est du SSD en ZFS.
Je reprends lundi et verrai avec un admin BDD de chez nous pour voir ce qu'il peut faire et je reviendrai vers le forum.
Je n'a pas la main sur le Tiers 3 et postgis 2.3 n'est pas encore disponible sur nos dépôts pour les clusters oracle, ça va l'objet d'un prochain packaging, l'urgence est de fournir nos propres tuiles sur notre infrastructure et on refera le papier peint après, une migration est assez rapide et faisable en parallèle.

Ce qui m'intéresserai le plus dans l'immédiat c'est ce qui est paramétré actuellement sur les PG d'OSM (work_mem, shared_buffer ...) car partir de valeurs déjà connues me feront gagner du temps sachant qu'il faudra les individualiser à notre infrastructure de toute manière.

Avatar de l’utilisateur
cquest
Messages : 1934
Inscription : ven. avr. 16, 2010 12:22 am
Localisation : Val de Marne
Contact :

Re: serveur de tuiles conseils paramétrage BDD PG

Message par cquest » ven. mai 12, 2017 3:00 pm

Les SSD sont locaux ?

Le problème de ces cluster haute-dispo c'est que pas forcément synonyme de haute-perf ;)

L'import c'est une chose, mais on ne le fait qu'exceptionnellement (idéalement une seule fois), donc ce n'est pas ça qu'il faut optimiser en priorité, même si le temps d'import est un bon indicateur des perf de la BDD.

Le tuning de PG dépend beaucoup de la config hardware de la machine... combien de RAM, combien de coeurs, latence et taux de transfert du stockage disque, disque unique ou multiples...

Pour osm13, le serveur a 64Go de RAM, mais il n'y a pas que PG (9.3) qui tourne dessus, il y a aussi mod_tile/renderd car il est autonome.

shared_buffer = 4GB
work_mem = 256MB
maintenance_work_mem = 1GB
effective_cache_size = 32GB (taille constatée de la RAM disponible et utilisée par le kernel pour le cache disque)

Sur SSD:
- effective_io_concurrency peut aussi valoir le coup d'être renseigné
- random_page_cost peut être réduit (j'ai 1.1) car les accès aléatoires ne sont pas beaucoup plus lents que les séquentiels vu qu'il n'y a pas de têtes à déplacer...

Pour aider le query planner:
- enable_seqscan=off : évite les seqscan à tout prix (sauf si aucun index dispo)
- default_statistics_target = 10000 : pour des stats sur le contenu des tables plus représentatifs vu la volumétrie de nos tables...

Si des requêtes sont vraiment lentes, il faut les logger et faire des EXPLAIN / EXPLAIN ANALYZE pour comprendre comment la requête est traitée réellement.

Les perf vont aussi grandement dépendre des requêtes elles-même... et donc de la feuille de style / config XML de mapnik.
Il faut vraiment tout bien aligner pour ne pas sortir du cas optimal.

Niarolf
Messages : 16
Inscription : jeu. avr. 06, 2017 9:35 am
Localisation : Hauts de Seine

Re: serveur de tuiles conseils paramétrage BDD PG

Message par Niarolf » ven. mai 12, 2017 5:16 pm

Merci pour ces précisions fortement importantes,
je fais un point dès lundi afin de donner plus de détails afin que ça profite également à ceux qui ont de gros besoins en tuiles !

Les disques sont multiples du fait que c'est du HNAS pour la haute disponibilité, donc oui pas l'idéal dans notre cas, mais ça se paramètre également pour que ça soit au plus mieux pour la qualité de service.
Je suis d'accord qu'éclater les services augmentent les latences réseaux et autres éléments comme la réplication mais je dois respecter le process de l'hébergeur sinon pas de service.
Chez nous haute disponibilité ne veut pas dire performances max mais pérennité du service en cas de crash (gestion de la continuité du service obligatoire) !

Avatar de l’utilisateur
cquest
Messages : 1934
Inscription : ven. avr. 16, 2010 12:22 am
Localisation : Val de Marne
Contact :

Re: serveur de tuiles conseils paramétrage BDD PG

Message par cquest » ven. mai 12, 2017 6:49 pm

Mettre des SSD derrière une couche IP c'est vraiment donner de la confiture à des cochons.

Quand les process de l'hébergeur sont inadaptés ça donne des services qui ne fonctionne pas ou mal ou coûtent bien plus chers qu'ils ne devraient.

Je préfère pas savoir ou c'est ;)

Répondre

Qui est en ligne ?

Utilisateurs parcourant ce forum : Aucun utilisateur inscrit et 3 invités