Re: postgre on virtual machine - Mailing list pgsql-general

From Craig Ringer
Subject Re: postgre on virtual machine
Date
Msg-id 4CBFDD5D.3080207@postnewspapers.com.au
Whole thread Raw
In response to Re: postgre on virtual machine  ("Joshua J. Kugler" <joshua@eeinternet.com>)
List pgsql-general
On 21/10/10 05:22, Joshua J. Kugler wrote:
> On Wednesday 20 October 2010, John R Pierce elucidated thus:
>> On 10/20/10 3:46 AM, Georgi Ivanov wrote:
>>> Hi,
>>> Is there any specific reason one should/should not run postgre on
>>> virtual machine for production ?
>>> Is there any special tuning for virtual environment ?
>>> Client of mine is running 8.4 on  virtual machine (VMWare ) so I'm
>>> wandering if there is anything special I can tune to speed up a
>>> bit. Also if I must choose between more RAM and more virtual cores
>>> what should I choose ?
>>
>> the biggest issue tends to be disk IO performance, especially in a
>> transactional intensive database.  virtualized storage is just not as
>> fast as native storage.   the big iron folks deal with this by
>> dedicating fiberchannel cards to each virtual machine that needs IO
>> performance.  of course, this gets expensive.
>>
>> as far as memory vs cores goes, that depends a lot on the nature of
>> your access patterns.   larger databases benefit from more memory for
>> caching & buffers, while higher levels of concurrent connections
>> benefit from more CPU cores (*and* more memory).
>
> Would using a raw partition in the VM alleviate some of the issues here?

Not really. Using accelerated virtualized I/O support using VT-IO or
similar may help a fair bit, though.

My main concern with any virtualized setup would be that the guest's
writes were properly flushed to the host's disk(s) when programs on the
guest fsync(). If the guest's writes aren't properly flushed before more
disk commands are processed, you are at risk of data loss and/or corruption.

Because forced disk flushes are slow, I won't be at all surprised if
many virtualization systems don't honour them. If you trust your host OS
to be 100% totally reliable, your UPSes to be perfect, and you have
REALLY good backups that might be OK. For the rest of us living in the
real world, that's a problem that has to be fixed before systems can be
used in production.

A good start to test for this issue is to see how many fsync() calls per
second your virtualized guest gets. If it's significantly more than the
host system running the test program unvirtualized, be very VERY
suspicious.

--
Craig Ringer

Tech-related writing: http://soapyfrogs.blogspot.com/

pgsql-general by date:

Previous
From: Thomas Kellerer
Date:
Subject: Re: Updates, deletes and inserts are very slow. What can I do make them bearable?
Next
From: Richard Huxton
Date:
Subject: Re: Upgrade from 8.3.3