Voilà, le rangement est terminé et les I/O ont bien baissé !
On était en moyenne à 85% d'utilisation des IO, on est maintenant plutôt
vers 15% à données identiques :)
Un gros index a quand même pris 36h à être regénéré, mais on a gagné
plus de 100Go dans la manip sur ce seul index.
On voit bien le changement
Le 27/06/2017 à 23:11, Christian Quest a écrit :
Un SSD a des temps d'accès (latence) moindres qu'un HDD, c'est sûr,
mais ce n'est pas aussi simple car il y a aussi une limite en bande
passante.
Les données sont stockées par blocs (4Ko sur les SSD/HDD actuels et
postgres segmente ses données par blocs de 8Ko).
Si j'ai besoin d'accéder à 100 noeuds différents, et que ceux-ci
occupent disons 40 octets en étant rangés sur des blocs différents
cela fera 100 accès disques... mais si ils sont rangés sur le même
bloc cela ne fera que 1 accès... pour lire la même quantité de données
UTILES... (comparer le ratio entre 100x4Ko lus et 4000 octets utiles,
même ratio d'usage utile dans le cache disque occupé en RAM).
Or, pour générer une tuile de fond de carte on a de très fortes
chances d'avoir besoin des points/lignes/polygones proches
géographiquement donc autant le ranger ensemble si possible sur les
mêmes blocs pour que la densité de données utiles lues soit maximale à
tout les niveaux.
J'ai mesuré une diminution d'un facteur 6 des IO après un CLUSTER
postgres. On verra dans quelques jours l'effet sur les graphes
d'activité du serveur osm13...
J'ai remis les slides de ma présentation du SOTM-2014 sur ce sujet sur
https://frama.link/_K9FdJtJ
--
Christian Quest - OpenStreetMap France
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
