[OSM-talk-fr] Mise à jour suspendue sur rendu HOT...
Christian Quest
cquest at openstreetmap.fr
Dim 2 Juil 08:58:39 UTC 2017
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
Plus d'informations sur la liste de diffusion Talk-fr