[OSM-dev-fr] "glonflement" des tables osm2pgsql...

Mar 12 Aou 14:55:08 UTC 2014

Le fill factor (taux de remplissage) est lié à l'orgnisation interne des
tables d'une base de données: les tables stockent les lignes par "pages" de
taille fixe dans lesquelles on agrège une ou plusieurs lignes; chaque page
est l'élement de base d'une organisation d'une des diverses variantes de
B-arbres. Dans chaque page il reste elors un espace inoccupé, et le "fill
factor" est le critère qui permet de savoir en dessous de quel taux
d'occupation il faut fusionner deux pages ou plus (lors des suppressions ou
mises à jour réduisant la taille d'une ligne), ou si on doit les éclater en
plusieurs parties (lors des insertions ou mises à jour augmentant la taille
d'une ligne).

Avec un "fill factor" élevé, les réorganisations agiront sur plus de pages
pour maintenir le taux remplissage souhaité dans toutes les pages. Pour des
tables ne subissant pas trop de mises à jour locales, un fill factor voir
de 85% est généralement bon, une réorganisation nécessitant de traiter
environ 5 ou 6 pages; le but du fill fator est donc d'établir un compromis
en terme de nombre de pages à réorganiser (les écritures sont plus longues:
si le taux est élevé, les réorgnisations seront plus fréquentes mais le
résultat sera une table plus compacte) et en nombre de pages d'I/O
nécessaires poru les accès en lecture (un taux élevé favorise une lecture
séquentielle plus rapide puisqu'il y aura plus de lignes par page lue dans
une seule I/O et puisque le cache en mémoire des pages sera plus efficace).

Si on fait un compactage complet, on obtient les lectures les plus rapides,
mais rapidement cela se dégrade puis ça se stabilise, car les insertions de
lignes dans la table ne tiendront pas dans les pages.

L'effet est moins critique si la table n'est pas elle-même un index
(autrement dit elle n'est pas triée, quelque soit l'organisation de tri
interne, même si c'est généralement un B-arbre dans les bases de données)
Mais la plupart des tables d'une base sont indexées (soit la table est
elle-même stockée comme index primaire, soit c'est un index secondaire
contenant seulement les clés). Si c'est un B-arbre, un fill-factor trop
faible diminue le "degré", c'est-à- dire augmente sa profondeur de la page
racine aux pages feuilles et donc augmente les temps d'accès en recherche
indexée.

Un fill factor ne devrait en principe jamais être inférieur à 50%, sauf
sans les tables très souvent mises à jour mais où il est acceptable
d'augmenter un peu le temps d'accès en lecture lors des accès indexés. Une
base de données a un paramétrage par défaut de ce fill factor pour les
index qu'elle gère. Ce fill factor est modifiable, mais une modification
entrainera une réroganisation de tout son contenu pour réapprocher au mieux
ce taux. souvent la valeur par défaut est voisine de 85%, mais en regardant
les statistiques d'I/O sur une table on peu voir si l'essentiel des accès
est passé à la maintenir pour réorgansier des pages (le moteur doit fournir
des stats sur les pages supplémentaires à lire/écrire lors des
fusion/scission de pages) ou si les accès indexés prenent trop de temps.

Selon l'usage constaté, on peut ajuster ce taux (par palier de 5% pour un
taux en dessous de 85%, ou par palier de 1%); plus on s'approche du taux
100% (taux impossible à égaler sauf dans les tables dont les lignes sont
toutes de taille fixe et sous-multiple de la taille de page), et plus les
réorganisations seront fréquentes : à 99% une réorganisation peut
nécessiter de traiter près de 200 pages à la fois (c'est donc coûteux en
I/O)...

Le 12 août 2014 13:47, Francescu GAROBY <f.garoby at gmail.com> a écrit :

> Et ça ne vaudrait pas le coup de modifier la fonction "pgsql_modify_node"
> que tu pointes pour lui faire faire un UPDATE, plutôt qu'un INSERT/DELETE ?
> La modification ne me paraît pas compliquée et si ça peut faciliter votre
> histoire de fillfactor (j'avoue ne pas comprendre de quoi il s'agit)...
>
> Francescu
>
>
> Le 12 août 2014 12:47, Christian Quest <cquest at openstreetmap.fr> a écrit :
>
> Par défaut le fillfactor sur les data est de 100%, d'où l'idée de le
>> baisser un peu... mais l'efficacité dépendra aussi de comment osm2pgsql met
>> à jour les données et vu le code ça semble malheureusement se faire à coup
>> de DELETE/INSERT et pas d'UPDATE...
>> https://github.com/openstreetmap/osm2pgsql/blob/master/output-pgsql.c#L1432
>>
>> Je ne suis pas sûr dans ces conditions que ça serve à grand chose.
>>
>>
>> Le 12 août 2014 11:37, Christophe Merlet <redfox at redfoxcenter.org> a
>> écrit :
>>
>> Le 12/08/2014 10:10, Christian Quest a écrit :
>>> > Vu qu'on a 2 bases osm2pgsql monde à la structure identique sur les
>>> > serveurs tile et layers, j'ai comparé l'espace occupé par les tables
>>> car
>>> > celui-ci est compté actuellement sur nos SSD de 480 (tile) et 512Go
>>> > (layers).
>>> >
>>> > Il y a des différentes plus ou moins importantes. La plus étonnante
>>> > concerne planet_osm_line qui pour les seules data fait 55Go sur tile et
>>> > 39Go sur layers, soit une différence de 40%.
>>> >
>>> > Je m'explique difficilement ces différences.
>>> >
>>> > Je viens de recopier la table (CREATE TABLE line as SELECT * FROM
>>> > planet_osm_line) et j'ai une table de 35Go. Il y a donc des trous dans
>>> > les data ou alors c'est un auto-vacuum en cours qui provoque ce
>>> > gonflement alors que je pensais qu'il prenait des données en fin de
>>> > fichier pour les remettre dans les trous.
>>> >
>>> > Des idées de votre côté ?
>>>
>>>
>>> L'auto vacuum est extrêmement limité. Il ne fait qu'indiquer les espaces
>>> réutilisables sans forcer leur réutilisation. C'est le VACUUM FULL qui
>>> permet de regagné l'espace disque. Mais pour se faire il faut au moins
>>> avoir l'équivalent de la plus grosse table en espace disponible et
>>> verrouiller les  tables en cours de traitement.
>>>
>>> Par ailleurs regagner l'espace disque n'est pas forcément une bonne
>>> idée, car, si je ne m'abuse, pgsql essaye d'insérer les données "au bon
>>> endroit". S'il y a des trous dans la base au bon endroit à cause d'une
>>> suppression précédente, c'est gagné, sinon il met là ou il peut.
>>>
>>> Ce sont les stats qui indique la meilleur stratégie.
>>>
>>> D'ailleurs, suivant l'espace disque disponible, il peut être judicieux
>>> de diminuer le fillfactor. ça laisse volontairement des trous dans la
>>> base pour insérer les nouvelles données
>>>
>>>
>>>
>>>         Librement,
>>> --
>>> Christophe Merlet (RedFox)
>>>
>>> _______________________________________________
>>> dev-fr mailing list
>>> dev-fr at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/dev-fr
>>>
>>
>>
>>
>> --
>> Christian Quest - OpenStreetMap France
>>
>> _______________________________________________
>> dev-fr mailing list
>> dev-fr at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/dev-fr
>>
>>
>
> _______________________________________________
> dev-fr mailing list
> dev-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev-fr
>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/dev-fr/attachments/20140812/5bb58cb3/attachment.html>