Own setup : dell precision 2*6 cores, 20 go RAM, SSD for index, 7200 HDD for big tables.
I do very different stuff with the server : - base for visualisation of classical vector table (Usually few users mostly reading.) - base for automatic road generation (topology + very very complex query) - interactive editing of road generation ( several users reading/writing + custom triggers) - point cloud server <https://github.com/Remi-C/Pointcloud_in_db> for point cloud import/export/visu - in base point cloud processing <https://github.com/Remi-C/Postgres_Day_2014_10_RemiC/blob/master/presentation/A%20PostgreSQL%20Server%20for%20Point%20Cloud%20Storage%20and%20Processing.pdf>, with lot's of python - in base point cloud classification <https://github.com/Remi-C/Octree_LOD_article/blob/master/OctreeLOD_LQ.pdf> (submitted, not yet accepted) Almost each of this usage has a different profile (simply displaying a vector table in qgis vs managing Billions of points ...) Cheers, Rémi-C 2015-02-10 21:15 GMT+01:00 George Silva <georger.si...@gmail.com>: > Others gave lots of good feedback, but let me chime in. > > >> * I didn't know about pgpool. It looks like it may come in handy if there >> connections become sluggish or simply impossible due to too many users. I >> will definitely keep this under my hat, although I understand it is a >> UNIX-only solution. >> > > Essential in a multiuser environment. > > >> * About usage being mostly read: this will be true for most "pure GIS" >> tasks (mostly intersecting), but I find that (from experience), we usually >> end up with a lot of intermediary tables for our analyses (new tables for >> the most part, not new columns). >> > > New tables and intersections or process that go somewhat like > Geoprocessing in ArcGIS (execute step 1, store the result in A, process B > with A, write in C, process C with D to get E) means that you will have a > lot of IO going on. If you have 10 students crunching numbers in PostGIS > writing new results together, this will mean significant IO. Get fast > disks. 15k RPM, 10k RPM or SSD. This can get your price tag to get a bit > high quickly. > > Mind that you can tune PostgreSQL to store you indexes in faster disks, > allowing you to store the bulk of your data on slower disks. If you have > the money, go with the fastest disks anywhere you can. > > >> >> * About MS vs. Linux based servers: same here, as long as the IT deal >> with it, I would be inclined to say this is not an issue (or at least this >> is not mine!). I agree though that, for a personal use (i.e. computer based >> in my lab), Linux systems are much easier to deal with (all my computers >> actually run Debian). But that's one the reasons I want a server in the >> center: it would come with a sysadmin who would deal with the hassle... I >> was thinking more in terms of possibilities here (remote access, linking >> PostGIS with R, etc.); in other words, do we lose anything *as a user* with >> a MS server? >> > > There are some articles (sorry, forgot where) that clearly state that > PostgreSQL performs much better in linux systems. Looks like not so much > these days. Check: > > > http://stackoverflow.com/questions/8368924/postgresql-performance-on-windows-using-latest-versions > > The good parts is that it's much easier, at least for me to admin services > and everything PostgreSQL need on linux. It's easier to install properly, > easier to configure it properly, amongst others. This is a personal > preference. If you can, go with linux (IMHO). > > >> Finally, may I ask you about your own setup (number of users, typical use >> cases, hardware specs, etc.)? It would probably help me. >> > > I have a company with 12 concurrent QGIS users, editing around 50.000km2 > of land use coverage in 1:5000 scale. It has a lot of detail. We do more > editing then processing, but there are some heavy stuff, such as "complete > feature" tool from QGIS, which in BIG geometries can take some time. > > My setup is: > > Bare metal machine with ESXI; > PostgreSQL machine with 8Gb RAM; > 2x processors quad-core; > PostgreSQL tuned for fast reads, large, large cache; > pgPool; > disks: 2 7.200RPM disks (I'm not at the office and I don't really remember > this, but I think this is 7.200rpm) - with RAID 1. > > Data is spread in two databases - meaning two non contiguous projects. > Each table has around 25k km2. > > We backup each database to a separate dump and upload it to rackspace. > > _______________________________________________ > postgis-users mailing list > postgis-users@lists.osgeo.org > http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users >
_______________________________________________ postgis-users mailing list postgis-users@lists.osgeo.org http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users