Thread: postgre on virtual machine

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 ?

2010/10/20 Georgi Ivanov <georgi.r.ivanov@gmail.com>:
> 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 ?
>

All is relative. But in some experiences, I saw good performance for
SOME applications
with virtual environments. It's all relative to the mass of
transactionality, load average,
number of GB of database, etc.

Try first to determinate the 'weight' of tasks that this DB could get.

Next, remember to have:
- good storage (amonut and speed)
- have the number of processors required to meet all the processes
that launch postgres
- redundance or good backups.

You can not spare RAM or CORES. What will tell you, the exact amount
of each other,
is 'how' the application will use the base.

If you share more details, maybe we could help a little more.



--
              Emanuel Calvo Franco
        DBA | www.emanuelcalvofranco.com.ar
Curso a distancia Nivel 1 Admin Postgres:
    http://www.postgresql-es.org/node/525

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).

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?

j

--
Joshua Kugler
Part-Time System Admin/Programmer
http://www.eeinternet.com - Fairbanks, AK
PGP Key: http://pgp.mit.edu/  ID 0x73B13B6A

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/