[OSM-talk-fr] Coup de turbo sur le rendu BANO...

[Philippe Verdy]

Le compactage des index a un effet limité: si cela varie autant c'est que
tu n'as pas joué sur les paramètres de taux de remplissage des pages de
B-tree et que tu l'as laissé à sa valeur minimale de 50% (qui a l'avantage
d'accélérer les mises à jour au prix d'une augmentation de l'espace total
utilisé de +50% en moyenne). Passer le taux de remplissage minimal des
pages à 75-80% a un impact faible sur les mises à jour (typiquement une
mise à jour écrira un peu plus souvent 3 ou 4 pages de plus en cas de
scission/fusion de pages mais pas si souvent que ça: si le plus gros des
usages des index est en lecture pour faire un rendu des cartes, tu as
intérêt à monter ce taux de remplissage.

A 80% de taux de remplissage sans aucune maintenance de compactage la
taille des index ne sera augmentée en moyenne que de 10%, mais en lecture
tu augmenteras énormément l'efficacité du cache de pages en mémoire. Si 80%
te fais peur, essaye déjà à 75% (qui réduit déjà d'environ 2 pages mises à
jour en moins par rapport au taux de 80%, quand il y a fusion ou scission
de page, et diminue aussi la fréquence des fusions/scission de page
d'environ 30% lors des mises à jour d'index). Tu n'auras plus ensuite à
t'occuper de réindexer (ce qui pénalise en bloquant la base souvent trop
longtemps).

En général dans les bases de données j'ai toujours utilisé le taux de 75%
(mais sur des bases relationnelles d'entreprise sur lesquelles on fait de
nombreuses analyses statistiques et des recherches très dispersées de
clients, fournisseurs, factures, etc... on utilise typiquement le 80% par
défaut, et on ajuste ensuite en fonction de l'audit. Certains moteurs de
bases de données disposent d'outil d'audit automatiques qui peuvent
autoajuster ces taux en surveillant les I/O et regardant les plans
d'exécution et succès/échecs de prédiction de leur optimiseur de requêtes,
ou encore les temps de réponse attendus par les clients selon que ce sont
des requêtes interactives venant de nombreux clients ou des requêtes
d'analyse d'origine plus locale mais en masse et venant d'un moteur
statistique (ces moteurs pour monter des cubes ont plutot tendance à
utiliser une base répliquée et indexée très différemment pour ne pas
pénaliser les consultations et mises à jour interactives: là on est dans ce
cas directement pour ta base destinée au rendu local)

A voir aussi quel index tu as besoin de mettre en "cluster" de la table
principale et quel index tenir séparé : l'index primaire n'est pas
forcément (et en fait est rarement) le mieux à placer en cluster quand il
peut être beaucoup plus compact (un index primaire ne contient souvent que
la clé unique) Voir aussi comment cette table indexée est accédée: en mode
aléatoire par des jointures très sélectives depuis une autre table (dans ce
cas un index séparé est meilleur), ou bien par intervalle essentiellement
en mode séquentiel sur cette clé (là on a intérêt à utiliser le cluster sur
cet index).

Il n'y a pas de solution miracle: un audit de performance basé sur
l'utilisation réelle et des statistiques et sélectivité donne de meilleures
pistes qu'une simple estimation basée sur la volumétrie globale.

Autre piste à explorer: séparer les temps où la base sert à faire du rendu
et les temps où elle fait des mises à jour en intégrant les "diffs". Faire
les deux en même temps (dans des processes indépendants) peut être très
pénalisant. On doit pouvoir déterminer des seuils de tâches à faire donnant
priorité à un type de tâche ou à l'autre et inclure une fraction de temps
destinée à la maintenance de la base elle-même (surveillance du taux de
remplissage global des pages, ou mise à jour des pages statistiques de
sélectivité utilisées par l'optimiseur interne des plans d'exécutions de
requêtes).


Le 5 février 2017 à 16:05, Christian Quest <cquest at openstreetmap.fr> a
écrit :

> Un peu d'optimisation faite hier dans postgresql sur le serveur BANO, ou
> plus exactement du "debloating d'index" c'est à dire la regénération des
> index des données BANO qui a permis de gagner 80Go d'espace disque (sur
> 200).
>
> Ceci devrait nettement améliorer le temps de génération des tuiles BANO
> qui s'était fortement ralentit ces derniers temps...
>
> J'ai aussi rechargé les adresses BAN (en gris).
>
>
> --
> Christian Quest - OpenStreetMap France
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20170205/d759dc6c/attachment.htm>