Re: [OSM-talk-fr] Mise à jour suspendue sur rendu HOT...
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
Re: [OSM-talk-fr] Mise à jour suspendue sur rendu HOT...
Je ne pense pas en effet que la fragmentation des fichiers sur SSD est un problème. En fait toute écriture sur SSD se fait en recyclant de nouveaux secteurs déjà "trimmés." Cependant pour trimmer les secterurs c'est un peu plus lent qu'une écriture normale mais c'est une opération nécessaire avant de pouvoir les réécrire. De fait un SSD ne trimme pas les secteurs tout seul et ne le fait qu'à la demande de l'OS. Si le SSD devient très plein, les anciens secteurs qui ont été réécris sont marqués comem "dirty" (à trimmer) avant de pouvoir être à nouveau disponibles pour l'écriture. Quand le SSD se remplit, les trims sont de plus en plus fréquents et sur un nombre moins élevé de secteurs : si on se contente de toujours écrire sur ces derniers secterus libres, ils vont vite dépasser leur nombre d'écriture maxi et produire des erreurs (ils sont ineffaçables et les nouveaux secteurs doivent être alloués parmi les autres secteurs trimmés). Pour égaliser la durée de vie moyenne des secteurs, une petite table statistique interne découpe le SSD en "bandes" et les bandes sont recyclés régulièrement (par l'OS) en réécrivant les secteurs occupés (sans réellement les modifier) afin de déplacer progressivement le pool de secteurs trimmés sur toute la surface. C'est un processus cyclique, l'OS indique au SSD quand il est opportun de recycler des secteurs trop souvent trimmés (donc réécrits aussi trop souvent) pour y mettre à la place des données stables encore stockées dans des secteurs moins souvent écrits. Le SSD possède en plsu un petit pool de secteurs de secours qui servira en cas de trop plein mais qui doivent être vite libéré. Ce pool libre sert avant tout pour permettre la récupération en cas de coupure d'alimentation ou plantage du système afin d'assurer l'intégrité: il doit pouvoir stocker les données non encore écrites qui sont dans le petit antémémoire cache (constitué non pas de mémoire flash mais de RAM plus classique et plus rapide ne nécessitant aucun trim) Bref les performances commencent à se dégrader au delà des 60% d'occupation, certains SSD affichant des performances en écriture déjà deux fois moins élevée quand ils sont seulement à moitié plein. Un SSD ne devrait jamais être utilisé au delà des deux tiers de la capacité maximale, sinon même les données stables sont exposées à des risques et les performances se dégradent vite. Bref il faut faire le ménage si on veut de bonnes performances en écriture. En revanche en lecture cela n'a normalement pas d'influence sur les performances: un SSD protégé en écriture aura une excellente durée de vie, mais là aussi la mémoire flash doit de temps en temps être raffraichie: les secteurs en lecture seule se recyclent donc aussi. Le firmware des SSD s'en occupe très lentement quand il n'est pas occupé à faire autre chose. L'autre problème des SSD est qu'ils n'ont pas seulement des secteurs de données mais aussi des secteurs de "tags" qui permettent de stocker l'indirection des secteurs virtuels (vus pas les système de fichier de l'OS) en secteurs physiques. Cette indirection se fait par bloc minimal de 4Ko là où les secteurs logiques font seulement 0,5Ko pour les OS et les protocoles ATA/PATA/SATA/SCSI et l'adressage LBA en général. Le but étant réduire la place nécessaire pour la mémoire de tags, contituée aussi de secteurs de mémoire Flash et qui doit elle aussi être recyclée (mais avec un algorithme complètement différent sans placement "aléatoire" comme les secteurs de données). Les algos utilisés pour la mémoire de tags varient selon les constructeurs et firmwares de SSD. La mémoire de tags peut aussi avoir (et en général elle en a) elle aussi un cache de RAM volatile: comme les tags sont les données du SSD les plus souvent accédées, ce cache doit être très rapide, c'est souvent des registres CMOS, mais là aussi il faut une réserve d'énergie pour assurer l'intégrité. Parfois des secteurs flash commenceront à avoir des problèmes sur certains bits et pas d'autres, ils ont tous un contrôle de parité/CRC poru détecter ces erreurs, et c'est vrai aussi de la mémoire de tags. Certains SSD utilise pour les tags (le même pool de secteurs mémoire Flash, mais évitent la fin de vie prématurée en mettant un cache volatile important en face: c'est un cache en écriture différée, il peut être plus gros que le cache d'écriture des données, par exemple 64Mo pour les tags contre seulement 4Mo pour les données, notamment sur les très gros SSD les plus chers dont le cache couteux de données ne monte pas autant en capacité que le cache des tags). On trouve aussi des SSHD, couplant un gros HDD (fiable) à un petit SSD frontal mais sans recyclage: ce SSD au cours du temps voit sa capacité diminuer, le cache SSD est un peu moins performant au fil du temps, et peut aussi avoir un cache de RAM volatile rapide. Sa mémoire de tags (pour associer les numéros de secteurs du disque dur à une page de cache SSD est moins critique. Mais cela apporte de la fiabilité aux HDD en réduisant les
Re: [OSM-talk-fr] Mise à jour suspendue sur rendu HOT...
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 Le 27 juin 2017 à 22:06, Alarig Le Laya écrit : > > C’est sûrement une question bête, mais l’intérêt des SSD n’est pas > justement d’avoir le même temps de réponse même si les données sont > éparpillées car il n’y a pas besoin d’attendre que la tête arrive sur le > bon secteur ? > Après, je n’ai jamais eu d’infra où j’arrive au bout des I/O d’un SSD, > donc je ne sais pas… > > -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise à jour suspendue sur rendu HOT...
On mar. 27 juin 18:29:28 2017, Christian Quest wrote: > Besoin de maintenance car le SSD où sont stockées les données dépassait les > 90% d'occupation depuis quelques semaines et qu'un peu de ménage est > nécessaire pour remettre de l'ordre dans les données. En effet, avec des > mises à jour toutes les 5mn, les données se retrouvent très dispersées sur > le disque au bout d'un certain temps, du coup les I/O augmentent, les perf > baissent... j'avais fait une présentation au SOTM sur ce sujet à Buenos > Aires ;) C’est sûrement une question bête, mais l’intérêt des SSD n’est pas justement d’avoir le même temps de réponse même si les données sont éparpillées car il n’y a pas besoin d’attendre que la tête arrive sur le bon secteur ? Après, je n’ai jamais eu d’infra où j’arrive au bout des I/O d’un SSD, donc je ne sais pas… -- alarig signature.asc Description: PGP signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Mise à jour suspendue sur rendu HOT...
Petit message pour indiquer que la base de données qui sert au rendu HOT est en maintenance d'été... j'ai donc suspendu sa mise à jour. Besoin de maintenance car le SSD où sont stockées les données dépassait les 90% d'occupation depuis quelques semaines et qu'un peu de ménage est nécessaire pour remettre de l'ordre dans les données. En effet, avec des mises à jour toutes les 5mn, les données se retrouvent très dispersées sur le disque au bout d'un certain temps, du coup les I/O augmentent, les perf baissent... j'avais fait une présentation au SOTM sur ce sujet à Buenos Aires ;) L'effet est bien visible sur ce graphique: https://munin.openstreetmap.fr/static/dynazoom.html?cgiurl_graph=/munin-cgi/munin-cgi-graph_name=openstreetmap.fr/osm13.openstreetmap.fr/diskstats_utilization/sda_x=800_y=400_epoch=1464020657_epoch=1498580657 Donc, recréation en cours d'un GROS index (plus de 100Go), il est même plus gros que les data qu'il sert à indexer, ce qui devrait au passage réduire sa taille de moitié ! -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr