<div dir="ltr">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.<div><br></div><div>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).</div><div><br></div><div>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)<div><br></div><div>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).</div><div><br></div><div>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.</div></div><div><br></div><div>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).</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">Le 5 février 2017 à 16:05, Christian Quest <span dir="ltr"><<a href="mailto:cquest@openstreetmap.fr" target="_blank">cquest@openstreetmap.fr</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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).<div><br></div><div>Ceci devrait nettement améliorer le temps de génération des tuiles BANO qui s'était fortement ralentit ces derniers temps...</div><div><br></div><div>J'ai aussi rechargé les adresses BAN (en gris).<span class="HOEnZb"><font color="#888888"><br><div><br clear="all"><div><br></div>-- <br><div class="m_-293424953683752984gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Christian Quest - OpenStreetMap France</div></div>
</div></font></span></div></div>
<br>______________________________<wbr>_________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org">Talk-fr@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-fr" rel="noreferrer" target="_blank">https://lists.openstreetmap.<wbr>org/listinfo/talk-fr</a><br>
<br></blockquote></div><br></div>