[OSM-dev-fr] 10 bonnes raisons de passer sous Postgresql 9.1 ?
Gilles Bassière
gbassiere at gmail.com
Lun 25 Juin 08:54:18 BST 2012
Bonjour Philippe,
J'avais vaguement retenu que la vitesse d'accès au disque était un
facteur clé de succès d'un serveur de réplication de base OSM. Il y a
bien sûr plusieurs façon d'agir sur ce paramètre. Mais sur la page de
benchmark d'osm2pgsql [1], on voit que SSD s'en tire plutôt mieux face à
d'autres serveurs pourtant bien mieux lotis en mémoire vive (donc en
cache) et/ou en niveaux de RAID.
Cela dit, mes propres expériences en réplication OSM m'ont montré qu'il
y a de multiples façons de faire un serveur de réplication efficace.
N'ayant moi-même pas accès au SSD, j'aimerais connaître la configuration
(matérial + paramètres) qui te permet d'arriver à des performances
similaires à du SSD sans SSD. Idéalement, pourrais-tu publier ta
configuration sur la page sus-citée afin que toute la communauté en
bénéficie ?
[1] http://wiki.openstreetmap.org/wiki/Osm2pgsql/benchmarks
Cordialement
Gilles
Le samedi 23 juin 2012 à 16:50 +0200, Philippe Verdy a écrit :
> Les SDD c'est juste pour du logiciel facilement réinstallable, mais
> très sollicité, pas pour des données instables en constante
> modification. La rapidaité des traitements dépend toutefois
> essentiellement d'autre chose : la mémoire interne mais surtout les
> alogorithmes utilisés.
> Et la mise à jour si elle permet de supporter de meilleurs algorithmes
> d'indexation ou de recherche, ou de supporter un meilleur parallélisme
> avec moins de dépendances et bloquages entre threads ou des
> transactions plus unitaires et demandant moins de modifications sur
> les mêmes objets et index, sera toujours un bonus pour lesquels les
> SSD ne sont là que pour essentiellement charger le logiciel.
> pour un nouyau Linux, une base SQL et un serice HTTP, un petit SDD de
> 256Mo suffit largement, pour le reste il vaut mieux monter du RAID 5
> ou plus (au moins 5 volumes physiques) qui offre des performances
> similaires. pour le parallélisme.
>
> Beaucoup de mémoire permettra d'installer un partition de travail pour
> les fichiers temporaires en mémoire (par exemple les tables de tri
> pour les requêtes), mais surtout servira d'antémémoire pour les
> disques. Mettre du SSD sur un serveur pour ses données c'est un crime,
> à moins que ce ne soit que pour des données cachables fréquemment
> sollicitées mais toujours reconstructibles, telles que les données de
> certaines requêtes fréquentes, une copie des styles CSS pour les
> tracés ou les pages web et javascripts du site web (au démarrage on
> s'assure juste de resycnhroniser à partir d'une image stockée sur
> RAID.
> En multithread sur des volumes transactionnels importants j'ai noté
> déjà que même un SSD est plus lent qu'un bon RAID pour tout ce qui est
> des accès en écriture.
> Enfin il faut prendre du matériel qui tient la route : toute
> maintenance à faire dans un datacenter coûte plus cher que le matériel
> lui-même... tout ce qui peut la fiabiliser (notamment le
> refroidissement, et le monitoring complet et intelligent de l'énergie
> utilisée) sera utile. Les SSD n'ont pas beaucoup d'options et sont
> toujours trop petits pour ce qu'on veut stocker ou générer.
>
> Le 22 juin 2012 11:16, sly (sylvain letuffe) <liste at letuffe.org> a écrit :
> > On vendredi 22 juin 2012, Lapinos03 wrote:
> >> Merci pour vos réponses.
> >>
> >> En fait, je me demandais surtout si PGSQL v9.1 serait plus rapide que
> >> v8.4 dans le processus de mise à jour d'une base via osm2pgsql, et lors
> >> du rendu mapnik.
> >
> > J'ai rien remarqué de notable, il vaut mieux mettre des disques SSD que de
> > changer de version de postgresql ;-)
> >
> >> jours, et jouer du droit de rétractation conformément aux CGV
> >
> > Mais quel fourbe, ça ne m'étonne donc plus que ces boites soit hyper méfiantes
> > vis à vis de leur client !!
> >
> > --
> > 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/
Plus d'informations sur la liste de diffusion dev-fr