2009/9/29 sly (sylvain letuffe) <sylv...@letuffe.org> > Je serais très curieux de voir des benchs comparatifs entre une solution > "plus > de RAM" et une solution "plus de disques" (histoire de savoir où > investir :-) ) >
Je ne peux pas vraiment fournir de benchs car on ne fait que de la lecture seule. Le load test tool que j'ai écrit il y a quelques temps montre que je n'arrive pas a maxer les serveurs postgresql a partir de ma machine :) Au final, ce que l'on voit, ce sont les temps de latence provenant du serveur. Il faut que je prenne le temps un jour de faire un beau test Jmeter afin de bien mettre en valeur l'augmentation de performances que l'on a eus. Il n'y a qu'un import tous les 2 mois. L'import et toutes les étapes prennent environ une semaine du fait du preprocess. > Mais aussi, selon la taille du fichier osm. Je me doute bien que si toute > la > base postgis tient en RAM ça doit dépoter sévère. > > Oui mais pas forcement, ça dépend aussi de la géométrie que tu utilises et la manière dont tu utilises tes fonctions. Disons qu'une géométrie LINESTRING se cache très bien et pour l'utilisation que j'en fais c'est absolument génial. Les polygones sont aussi très efficaces a cacher surtout si tu as beaucoup de mémoire. Par contre, le problème et le point noir ce sont les points. C'est de loin le plus lent sur les requêtes que je fais (un ordre de magnitude plus lent). Je travaille sur le monde entier. Il y a bien sur des moyens de biaiser pour augmenter les performances selon ce que tu recherches. Les partitions tables sont une de ces solutions. > > Question bête: lisez vous les fichiers directement en bz2 ou ont ils été > > décompressés? > > Moi bz2 toujours, c'est plus simple et... sisi, plus rapide ;-) > Mon serveur a du cpu à revendre durant les imports, par contre, pas les > io... > En effet, c'est mieux d'utiliser bz2. C'est beaucoup plus rapide et ça réduit sérieusement les IO. En moyenne, le ratio de compression est d'environ 20. Emilie Laffray
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
