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) <[email protected]> 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 > > [email protected] > > http://lists.openstreetmap.org/listinfo/dev-fr > > _______________________________________________ > dev-fr mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/dev-fr -- Gilles Bassière - Web/GIS software engineer http://gbassiere.free.fr/ _______________________________________________ dev-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev-fr
