Re: driving postgres to achieve benchmark results similar to bonnie++

From: Mike Broers <mbroers(at)gmail(dot)com>
To: Kevin Grittner <kgrittn(at)gmail(dot)com>
Cc: Scott Whitney <scott(at)journyx(dot)com>, John Scalia <jayknowsunix(at)gmail(dot)com>, "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org>
Subject: Re: driving postgres to achieve benchmark results similar to bonnie++
Date: 2016-05-11 15:16:26
Message-ID: CAB9893iitE_qKK7Bvmo8a-N3QLh=r3=KOHFhMVp5HDpxRJh4Sg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

I've set this parameter to 256 to test, still getting the same results.
The only way I reliably see a spike in IO at all is on the pgbench
initialization (still peaking around 110MB/sec writes), so I'm thinking
about playing around with that or duplicating its approach with larger rows
and running it from multiple sessions in different initialization databases
on the same volume. If I cant push it further using that technique then
there must be some dumb bottleneck in config I am overlooking.

On Tue, May 10, 2016 at 3:24 PM, Kevin Grittner <kgrittn(at)gmail(dot)com> wrote:

> On Tue, May 10, 2016 at 2:02 PM, Mike Broers <mbroers(at)gmail(dot)com> wrote:
>
> > If someone has an idea for how to set up pgbench to
> > really push the io to prove out ssd potential, or a different
> > script/approach that would be awesome.
>
> You might want to play with some large effective_io_concurrency
> settings, starting around 256.
>
>
> http://www.postgresql.org/message-id/CAHyXU0yiVvfQAnR9cyH=HWh1WbLRsioe=mzRJTHwtr=2azsTdQ@mail.gmail.com
>
> --
> Kevin Grittner
> EDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Mike Broers 2016-05-11 15:47:11 Re: driving postgres to achieve benchmark results similar to bonnie++
Previous Message Ondřej Světlík 2016-05-11 12:06:47 Re: Autovacuum of pg_database