[postgis-users] Hardware requirements for a server

[Rémi Cura]

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.silva at 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 at lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20150211/73c27dc3/attachment.html>