Re: [OSM-dev-fr] 10 bonnes raisons de passer sous Postgresql 9.1 ?
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) 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@openstreetmap.org > > http://lists.openstreetmap.org/listinfo/dev-fr > > ___ > dev-fr mailing list > dev-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/dev-fr -- Gilles Bassière - Web/GIS software engineer http://gbassiere.free.fr/ ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinf
Re: [OSM-dev-fr] 10 bonnes raisons de passer sous Postgresql 9.1 ?
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) 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@openstreetmap.org > http://lists.openstreetmap.org/listinfo/dev-fr ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] 10 bonnes raisons de passer sous Postgresql 9.1 ?
> 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@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] 10 bonnes raisons de passer sous Postgresql 9.1 ?
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) 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@openstreetmap.org > > http://lists.openstreetmap.org/listinfo/dev-fr > > ___ > dev-fr mailing list > dev-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/dev-fr -- Gilles Bassière - Web/GIS software engineer http://gbassiere.free.fr/ ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] 10 bonnes raisons de passer sous Postgresql 9.1 ?
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) 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@openstreetmap.org > http://lists.openstreetmap.org/listinfo/dev-fr ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] 10 bonnes raisons de passer sous Postgresql 9.1 ?
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@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] 10 bonnes raisons de passer sous Postgresql 9.1 ?
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. Je pourrais relouer un serveur identique au mien chez Online, pour 7 jours, et jouer du droit de rétractation conformément aux CGV, et ainsi constater par moi-même, mais l'ayant déjà fait une fois et n'étant toujours pas remboursé après plus de 30 jours, délai légal, malgré des relances (- voilà, je balance sur Online -), je ne suis pas prêt de retenter le coup. Alors si quelqu'un a une expérience de ce côté-là...? Enfin, j'imagine que cela ne pourrait pas être pire sous v9.1, mais sait-on jamais... A+ /Lapi ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] 10 bonnes raisons de passer sous Postgresql 9.1 ?
Le lundi 18 juin 2012 à 23:53 +0200, sly (sylvain letuffe) a écrit : > Le lundi 18 juin 2012 23:35:34, Lapinos03 a écrit : > > Avé ! > > > > Je suis toujours sous pqsql 8.4.11. > > Je me demandais si ça valait vraiment la peine de passer sous la > > dernière version... (vu le temps que ça va prendre de réinstaller la > > base complètement) > > > > Quelqu'un a-t-il 10 bonnes raisons de me convaincre ? > > La réponse 0 est : "ça dépend" > (ben ouais, tu dis pas pour quoi faire) > Je vais donc supposer un usage avec un schéma osm2pgsql pour du rendu > > Je me lance pour 10 raisons (en binaire) : > > 1 : tu n'as rien à y gagner sinon ça te manquerait déjà > 10 : tu va perdre plusieurs heures à gérer une ré-importation et comprendre > que les modules ne s'activent plus de la même façon Je suis assez d'accord avec le point 0 :) Pour le reste, la migration se fait bien en général : dump de tes bases, upgrade de postgres/postgis, restore de tes bases, script de mise à jour de postgis. Pour les nouveautés, je suis assez fan de: * Système d'extension de postgres 9.1. Tu n'as plus besoin de charger des scripts SQL ou utiliser un template pour activer PostGIS. Les sauvegardes en sont grandement simplifiées (PostgreSQL comprend que PostGIS est un bibliothèque tierce, il ne la traite plus comme des objets de l'utilisateur). Tu sentiras l'intérêt pour les nouvelles bases que tu vas créer, tes anciennes bases n'en bénéficieront pas (à moins d'y désinstaller PostGIS et de le ré-installer avec la méthode moderne). * Type geometry dynamique : tu peux créer une colonne "à la régulière", par exemple : CREATE TABLE (id serial, geom geometry(POINT, 4326)); Tu n'as plus besoin d'utiliser AddGeometryColumn dans une requête séparée (c'était une hérésie vis-à-vis de la norme SQL). En corollaire, geometry_columns est maintenant une vue, plus besoin de la maintenir à jour. Ça ne fait pas 10 bonnes raisons, mais c'est déjà deux grosses bonnes raisons à mon humble avis. En cadeau bonus, il y a ces nouvelles fonctionnalités dont tout le monde parle : * support des rasters (ça peut être pratique mais je trouve pas ça flambant pour le moment, c'est encore assez pauvre fonctionnellement) * support de la topologie : ça peut envoyer de la buchette :) probablement un peu délicat à prendre en main mais ça devrait ouvrir des voies de solutions à de nombreux problèmes. Cordialement -- Gilles Bassière - Web/GIS software engineer http://gbassiere.free.fr/ ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] 10 bonnes raisons de passer sous Postgresql 9.1 ?
Le lundi 18 juin 2012 23:35:34, Lapinos03 a écrit : > Avé ! > > Je suis toujours sous pqsql 8.4.11. > Je me demandais si ça valait vraiment la peine de passer sous la > dernière version... (vu le temps que ça va prendre de réinstaller la > base complètement) > > Quelqu'un a-t-il 10 bonnes raisons de me convaincre ? La réponse 0 est : "ça dépend" (ben ouais, tu dis pas pour quoi faire) Je vais donc supposer un usage avec un schéma osm2pgsql pour du rendu Je me lance pour 10 raisons (en binaire) : 1 : tu n'as rien à y gagner sinon ça te manquerait déjà 10 : tu va perdre plusieurs heures à gérer une ré-importation et comprendre que les modules ne s'activent plus de la même façon -- sly (sylvain letuffe) ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
[OSM-dev-fr] 10 bonnes raisons de passer sous Postgresql 9.1 ?
Avé ! Je suis toujours sous pqsql 8.4.11. Je me demandais si ça valait vraiment la peine de passer sous la dernière version... (vu le temps que ça va prendre de réinstaller la base complètement) Quelqu'un a-t-il 10 bonnes raisons de me convaincre ? Merci /Lapi ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
