Re: Unexpected pgbench result

From: Shaun Thomas <sthomas(at)optionshouse(dot)com>
To: Dave Johansen <davejohansen(at)gmail(dot)com>, pgsql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Unexpected pgbench result
Date: 2013-12-19 17:44:09
Message-ID: 52B33069.1060203@optionshouse.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On 12/19/2013 11:00 AM, Dave Johansen wrote:

> When I run pgbench in "SELECT only" after doing "-i -s 2000" I get what
> appears to be good performance (60k-70k tps) but if I initialize a new
> database with "-i -s 4000" the tps drops to 4k-7k. Is this order of
> magnitude drop expected? Or is there something wrong with my hardware or
> database configuration that is causing this issue?

When you increase the size of the initialized pgbench tables, you
increase the size on disk. My guess is that you doubled it so that the
data no longer fits in memory. You can verify this yourself:

SELECT pg_size_pretty(sum(pg_database_size(oid))::bigint)
from pg_database;

Any amount of memory you have that is smaller than that, will affect
select performance. I can guarantee you will not get 60k-70k tps from
anything short of an array of SSD devices or a PCIe NVRAM solution. Your
'-s 2000' test was probably running mostly from memory, while the '-s
4000' did not.

What you're seeing is the speed your records are being supplied from
disk, plus whatever cache effects are there when records are read before
they are flushed in favor of more recent data.

--
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604
312-676-8870
sthomas(at)optionshouse(dot)com

______________________________________________

See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Shaun Thomas 2013-12-19 17:53:55 Re: Optimizing a query
Previous Message Pavel Stehule 2013-12-19 17:29:25 Re: Re: Problem with slow query with WHERE conditions with OR clause on primary keys