[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