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

[Philippe Verdy]

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