Обсуждение: 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 ?
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/