From: Mark Kirkwood <mark.kirkwood@catalyst.net.nz>
To: Scott Marlowe <scott.marlowe@gmail.com>
To: Don Seiler <don@seiler.us>
Cc: pgsql-performance@lists.postgresql.org
Subject: Re: Setting effective_io_concurrency in VM?
Date: Fri, 8 Dec 2017 17:51:08 +1300
Message-ID: <3b52abb7-37d5-d18c-d677-9f5052ffd4df@catalyst.net.nz> (raw)
In-Reply-To: <CAOR=d=1-W_Hqp8hmpcnCymW8=UpxdU1J8_nnsUmWA9RqhZw-gA@mail.gmail.com>
References: <CAHJZqBCAQYq46jdfNkJpaJ1SzeGnCjDnsMnGEod-_s7dEYGzow@mail.gmail.com>
<CAOR=d=1-W_Hqp8hmpcnCymW8=UpxdU1J8_nnsUmWA9RqhZw-gA@mail.gmail.com>
On 28/11/17 07:40, Scott Marlowe wrote:
> On Mon, Nov 27, 2017 at 11:23 AM, Don Seiler <don@seiler.us> wrote:
>> Good afternoon.
>>
>> We run Postgres (currently 9.2, upgrading to 9.6 shortly) in VMWare ESX
>> machines. We currently have effective_io_concurrency set to the default of
>> 1. I'm told that the data volume is a RAID 6 with 14 data drives and 2
>> parity drives. I know that RAID10 is recommended, just working with what
>> I've inherited for now (storage is high-end HP 3Par and HP recommended RAID
>> 6 for best performance).
>>
>> Anyway, I'm wondering if, in a virtualized environment with a VM datastore,
>> it makes sense to set effective_io_concurrency closer to the number of data
>> drives?
>>
>> I'd also be interested in hearing how others have configured their
>> PostgreSQL instances for VMs (if there's anything special to think about).
> Generally VMs are never going to be as fast as running on bare metal
> etc. You can adjust it and test it with something simple like pgbench
> with various settings for -c (concurrency) and see where it peaks etc
> with the setting. This will at least get you into the ball park.
>
> A while back we needed fast machines with LOTS of storage (7TB data
> drives with 5TB of data on them) and the only way to stuff that many
> 800GB SSDs into a single machine was to use RAID-5 with a spare (I
> lobbied for RAID6 but was overidden eh...) We were able to achieve
> over 15k TPS in pgbench with a 400GB data store on those boxes. The
> secret was to turn off the cache in the RAID controller and cranl up
> effective io concurrency to something around 10 (not sure, it's been a
> while).
>
> tl;dr: Only way to know is to benchmark it. I'd guess that somewhere
> between 10 and 20 is going to get the best throughput but that's just
> a guess. Benchmark it and let us know!
Reasonably modern Linux hosts with Linux guests using Libvirt/KVM should
be able to get bare metal performance for moderate numbers of cpus (<=8
last time we benchmarked). It certainly *used* to be the case that
virtualization sucked for databases, but not so much now.
The advice to benhmark, however - is golden :-)
Cheers
Mark
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: mark.kirkwood@catalyst.net.nz, scott.marlowe@gmail.com, don@seiler.us, pgsql-performance@lists.postgresql.org
Subject: Re: Setting effective_io_concurrency in VM?
In-Reply-To: <3b52abb7-37d5-d18c-d677-9f5052ffd4df@catalyst.net.nz>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox