Re: pgbench results on a new server - Mailing list pgsql-performance

From Greg Smith
Subject Re: pgbench results on a new server
Date
Msg-id 4C2A9C99.40303@2ndquadrant.com
Whole thread Raw
In response to Re: pgbench results on a new server  (Craig James <craig_james@emolecules.com>)
List pgsql-performance
Craig James wrote:
> synchronous_commit = off
> full_page_writes = off

I don't have any numbers handy on how much turning synchronous_commit
and full_page_writes off improves performance on a system with a
battery-backed write cache.  Your numbers are therefore a bit inflated
against similar ones that are doing a regular sync commit.  Just
something to keep in mind when comparing against other people's results.

Also, just as a general comment, increase in work_mem and
effective_cache_size don't actually do anything to the built-in pgbench
test results.

>> General numbers are OK, the major drop going from 30 to 40 clients is
>> larger than it should be. I'd suggest running the 40 client count one
>> again to see if that's consistent.
>
> It is consistent.  When I run pgbench from a different server, I get
> this:
>
>    pgbench -c40 -t 2500 -U test
>    tps = 7999
>
>    pgbench -c100 -t 1000 -U test
>    tps = 6693

Looks like you're just running into the limitations of the old pgbench
code failing to keep up with high client count loads when run on the
same system as the server.  Nothing to be concerned about--that the drop
is only small with the pgbench client remote says there's not actually a
server problem here.

With that sorted out, your system looks in the normal range for the sort
of hardware you're using.  I'm always concerned about the potential
reliability issues that come with async commit and turning off full page
writes though, so you might want to re-test with those turned on and see
if you can live with the results.

--
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com   www.2ndQuadrant.us


pgsql-performance by date:

Previous
From: Jignesh Shah
Date:
Subject: Re: PostgreSQL as a local in-memory cache
Next
From: Bruce Momjian
Date:
Subject: Re: PostgreSQL as a local in-memory cache