Re: Scaling shared buffer eviction

From: Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Scaling shared buffer eviction
Date: 2014-09-05 03:12:49
Message-ID: 54092A31.5000009@catalyst.net.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 04/09/14 14:42, Amit Kapila wrote:
> On Thu, Sep 4, 2014 at 8:00 AM, Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>
> wrote:
>>
>>
>> Hi Amit,
>>
>> Results look pretty good. Does it help in the read-write case too?
>
> Last time I ran the tpc-b test of pgbench (results of which are
> posted earlier in this thread), there doesn't seem to be any major
> gain for that, however for cases where read is predominant, you
> might see better gains.
>
> I am again planing to take that data in next few days.
>

FWIW below are some test results on the 60 core beast with this patch
applied to 9.4. I'll need to do more runs to iron out the variation, but
it looks like the patch helps the standard (write heavy) pgbench
workload a little, and clearly helps the read only case.

4x E7-4890 15 cores each.
1 TB ram
16x Toshiba PX02SS SATA SSD
4x Samsung NVMe XS1715 PCIe SSD

Ubuntu 14.04 (Linux 3.13)
Postgres 9.4 beta2
+ buffer eviction patch v5

Pgbench

scale 2000

Non default params:

max_connections = 400;
shared_buffers = "10GB";
maintenance_work_mem = "1GB";
effective_io_concurrency = 10;
wal_buffers = "256MB";
checkpoint_segments = 1920;
checkpoint_completion_target = 0.8;
ssl = 'off';
wal_sync_method = 'open_datasync';

read write

elapsed 600s

Clients | tps | tps (unpatched)
---------+-------+----------------
6 | 8279 | 8328
12 | 16260 | 16381
24 | 23639 | 23451
48 | 31430 | 31004
96 | 38516 | 34777
192 | 33535 | 32443
384 | 27978 | 25068
384 | 30589 | 28798

read only

elapsed 300s

Clients | tps | tps (unpatched)
---------+--------+----------------
6 | 57654 | 57255
12 | 111361 | 112360
24 | 220304 | 187967
48 | 384567 | 230961
96 | 380309 | 241947
192 | 330865 | 214570
384 | 315516 | 207548

Regards

Mark

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Laurence Rowe 2014-09-05 04:21:26 Re: A mechanism securing web applications in DBMS
Previous Message Fujii Masao 2014-09-05 03:10:32 Re: pg_receivexlog --status-interval add fsync feedback