[postgis-users] VMWare and PostGIS

[Jim Mlodgenski]

On Sat, Jan 12, 2013 at 11:39 PM, Paragon Corporation <lr at pcorp.us> wrote:

> **
> On a related topic, has anyone tried the VMware Postgres product.  I'd be
> curious to know how they optimized the performance for that and if it
> supports PostGIS.  I assume it does, but perhaps David Fetter if he's
> listening can fill us in on that.
>

I've used it a fair amount. Most of the performance optimizations are
around tuning, but they do have a cool feature where you can increase
shared buffers without restarting. The source is open so you can diff it
against 9.1.6 and see what they did.
https://my.vmware.com/web/vmware/details?downloadGroup=VFPG_9160_OSS_OSE&productId=274

The base database would support PostGIS, but I don't recall if its possible
through their Data Director interface. Data Director basically abstracts
away creating and running the database a little and in trade, you don't
have superuser rights. VMware would need to enable it through Data Director
somehow because a regular user couldn't enable it.


>
>
> http://www.vmware.com/products/application-platform/vfabric-postgres/overview.html
>
> Thanks,
> Regina
>
>  ------------------------------
> *From:* postgis-users-bounces at lists.osgeo.org [mailto:
> postgis-users-bounces at lists.osgeo.org] *On Behalf Of *Paul Ramsey
> *Sent:* Saturday, January 12, 2013 8:18 PM
> *To:* PostGIS Users Discussion
> *Subject:* Re: [postgis-users] VMWare and PostGIS
>
>  The most important thing is to figure out where your "fast enough" place
> is, and not get too hung up on the "fastest" thing. If we wanted to be
> fastest, we'd all drive Ducatis to work, but clearly fast enough works for
> most of us.
>
> The main problem with AWS is not the virtualization, it's the shared
> tenancy. It's possible for other tenants to saturate the I/O at
> unpredictable times, taking it from acceptable to non-existent, with no
> predicability. This will be true, though to a lesser extent, with private
> virtual environments, like shared VMWare hosts run by your IT department.
>  ("To a lesser extent" because AWS storage is network mounted, so
> everything the host does with I/O has to push out through a network pipe.
> Your IT department VMWare host, on the other hand, will at least have
> separate network and storage I/O channels.)
>
> I have heard of, but never seen, VMWare hosts that attach directly to SAN
> storage over iSCSI. So the host is virtual, but the storage is at full SAN
> speed. A "best of both worlds" situation, but with the added cost of SAN
> infrastructure.
>
> P.
>
>
> On Sat, Jan 12, 2013 at 4:36 PM, Stephen V. Mather <
> svm at clevelandmetroparks.com> wrote:
>
>>  Hi All,
>> I should have asked this a long time ago regarding performance... .  So
>> the classic storage solution (AFAIK) for a spatial database is RAID 10 for
>> maximum read and write speed.  I have a RAID 10 running under a
>> virtualization layer (VMWare in this case) and my sustained read speeds are
>> in the 1Gbps range.  The hardware is oldish, but they are 10k SAS drives,
>> so I would expect something a bit faster.
>>         To the question-- I know virtualization makes a (not-so-good)
>> difference in performance running spatial databases on e.g. Amazon EC2
>> instances.  I assume this penalty is paid even for dedicated private
>> clouds.  What is the consensus/experience with virtualization?  For my next
>> machine, should I keep it to bare metal for the PostGIS portion?
>>
>> Thanks in advance,
>> Best,
>> Steve
>>
>>   [image: http://sig.cmparks.net/cmp-ms-90x122.png] Stephen V. Mather
>> GIS Manager
>> (216) 635-3243 <%28216%29%20635-3243> (Work)
>> clevelandmetroparks.com <http://www.clemetparks.com>
>>
>>
>>
>> _______________________________________________
>> postgis-users mailing list
>> postgis-users at lists.osgeo.org
>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
>>
>>
>
> _______________________________________________
> 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/20130113/ccb8ce06/attachment.html>