[OSM-dev-fr] 10 bonnes raisons de passer sous Postgresql 9.1 ?

[Gilles Bassière]

Oui, OK. On est sur une liste dev, on est tous un peu geek et on lit
aussi des tas de choses sur le matos. On sait que les arguments anti-SSD
ne manquent pas, autant que les arguments pro-SSD d'ailleurs.

Mais la réplication d'une base OSM est un cas très particulier et, pour
ce cas précis, un positionnement anti-SSD est inattendu (compte tenu des
expériences déjà publiées). Ton argumentaire a donc un certain attrait
mais il doit être étayé, validé par une expérience concrète.

Peux-tu, s'il te plaît, décrire ta configuration et montrer les mesures
que tu as faites afin de crédibiliser ton propos ?

Cordialement
Gilles

Le lundi 25 juin 2012 à 17:18 +0200, Philippe Verdy a écrit :
> C'est une question de volume. LEs bases OSM de toute façon sont trop
> volumineuses pour tenir avec leurs index dans un SSD de taille
> raisonnable et à prix non prohibitf. Le taux de panne étant important
> plus le volume croit plus la fréquence des pannes augmente.
> Les solutions de RAID et de serveurs de fichiers en miroir fonctionne
> bien, augmentent la fiabilité, facilitent la maintenance (y compris
> les sauvegardes qui ne sont plus prohibitives en temps d'accès pendant
> qu'elles tournent quasiment en continu).
> 
> Il n'y a pas que la fiabilité des supports SSD en jeu. Les problèmes
> sont encore plus fréquents dans leurs interfaces et dans les complexes
> algorithmes de placement. Un SSD a aussi une zone très critique qui
> contient le mapping des secteurs : trop sollicitée c'est cette zone
> qui lâche la première et on se retrouve alors avec un méli-mélo de
> secteurs et de couteuses et longues tentatives de récupération.
> 
> 
> Le SSD reste très bien pour installer un kernel et les logiciels
> (partitions /, /bin, /usr et même /home, mais pas /tmp qui en revanche
> ira très bien dans un ramdisk). Ou alors on peut avoir un RAID dont
> chacun des disques est monté avec un frontal SSD transparent,
> détachable.
> Attention à la régulation de température des SSD: c'est souvent très
> mal fait. Le SSD est alors plus faible pour les interruptions de
> courant ou plantages système. Et marche mieux dans ce cas que la
> mémoire cache intégrée aux disques (souvent de l'ordre de 32Mo à 64
> Mo).
> 
> Mais le critère de coût/remplacement est encore prohibitif. C'est
> tellement plus simple d'ajouter des disques en stripe. On peut même
> utiliser des interfaces réseau pour connecter des disques en
> FiberChannel et paralléliser des serveurs.
> Je sais que les RAID en SSD seul ça existe, mais un projet
> OpenStreetMap quelconque n'a pas les moyens de se payer ça.
> 
> Autant acheter plutôt un autre serveur pour répartir les services y
> compris ceux de maintenance, ou pour tester de nouvelles versions et
> faciliter des migrations. Ou sinon pour ajouter un autre générateur de
> tuiles pour les plus hauts niveaux de zoom et avec assez d'espace pour
> garder du cache sans trop le soliciter et permettre des
> rafraichissements de tuiles plus rapides entre versions.
> 
> Ou acheter une carte contrôleur de plus pour éviter des goulots de
> bande passante sur un bus. Et privilégier l'optimisation du noyau et
> des logiciels pour le parallélisme en multhithread partout où c'est
> possible (pas la peine sinon d'avoir des cœurs en plus si on ne s'en
> sert pas). Enfin bien mettre au point les accès de monitoring et
> apprendre à gérer son serveur et vérifier que le déploiement est
> encore conforme aux attentes et usages (qui varient largement au cours
> du temps).
> 
> Le 25 juin 2012 14:13, sly (sylvain letuffe) <liste at letuffe.org> a écrit :
> >> pourrais-tu publier ta
> >> configuration sur la page sus-citée afin que toute la communauté en
> >> bénéficie ?
> >
> > Je serais moi aussi très intéressé par une publication de la part de philippe
> > d'un protocol experimental précis et des résultats d'une importation avec
> > osm2pgsql afin de donner un peu de concret à ses dirs (comparaison RAID/SSD)
> > qui semblent pour l'instant juste sortis du chapeau de la légende urbaine et
> > du bruit de couloir...
> >
> > Si cela confirme que les SSD n'apportent rien quand on y met les données de la
> > base postgresql crée par osm2pgsql, je re-considérerais certains choix que
> > j'ai fais, mais pour l'instant, je vais m'en tenir à mes propres benchmarks
> > que j'ai publié sur le wiki, faute de concret dans ce qu'annonce philippe.
> >
> > --
> > sly
> > qui suis-je : http://sly.letuffe.org
> > email perso : sylvain chez letuffe un point org
> >
> > _______________________________________________
> > dev-fr mailing list
> > dev-fr at openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/dev-fr
> 
> _______________________________________________
> dev-fr mailing list
> dev-fr at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/dev-fr


-- 
Gilles Bassière - Web/GIS software engineer
http://gbassiere.free.fr/