Re: Optimize kernel readahead using buffer access strategy

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: KONDO Mitsumasa <kondo(dot)mitsumasa(at)lab(dot)ntt(dot)co(dot)jp>
Cc: Claudio Freire <klaussfreire(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Peter Geoghegan <pg(at)heroku(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Subject: Re: Optimize kernel readahead using buffer access strategy
Date: 2013-12-17 12:29:34
Message-ID: CA+U5nMJjw+edsXszT8ZymFPepW67-Pcx16e-BDLG-v4uX_Noyw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 17 December 2013 11:50, KONDO Mitsumasa
<kondo(dot)mitsumasa(at)lab(dot)ntt(dot)co(dot)jp> wrote:

> Unpatched PG is faster than patched in A and B query. It was about 1.3 times
> faster. Result of A query as expected, because patched PG cannot execute
> readahead at all. So cache cold situation is bad for patched PG. However, it
> might good for cache hot situation, because it doesn't read disk IO at all
> and can calculate file cache usage and know which cache is important.
>
> However, result of B query as unexpected, because my patch select
> POSIX_FADV_SEQUNENTIAL collectry, but it slow. I cannot understand that,
> nevertheless I read kernel source code... Next, I change
> POSIX_FADV_SEQUNENTIAL to POISX_FADV_NORMAL in my patch. B query was faster
> as unpatched PG.
>
> In heavily random access benchmark tests which are pgbench and DBT-2, my
> patched PG is about 1.1 - 1.3 times faster than unpatched PG. But postgres
> buffer hint strategy algorithm have not optimized for readahead strategy
> yet, and I don't fix it. It is still only for ring buffer algorithm in
> shared_buffer.

These are interesting results. Good research.

They also show that the benefit of this is very specific to the exact
task being performed. I can't see any future for a setting that
applies to everything or nothing. We must be more selective.

We also need much better benchmark results, clearly laid out, so they
can be reproduced and discussed.

Please keep working on this.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2013-12-17 12:48:05 Re: logical changeset generation v6.8
Previous Message MauMau 2013-12-17 12:26:49 [bug fix] connection service file doesn't take effect with ECPG apps