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
