Re: Introducing a new linux readahead framework

Поиск
Список
Период
Сортировка
От Wu Fengguang
Тема Re: Introducing a new linux readahead framework
Дата
Msg-id 20060421071511.GA4885@mail.ustc.edu.cn
обсуждение исходный текст
Ответ на Re: Introducing a new linux readahead framework  ("Jim C. Nasby" <jnasby@pervasive.com>)
Ответы Re: Introducing a new linux readahead framework  (Markus Schaber <schabi@logix-tt.com>)
Список pgsql-performance
On Thu, Apr 20, 2006 at 11:31:47PM -0500, Jim C. Nasby wrote:
> > In adaptive readahead, the context based method may be of particular
> > interest to postgresql users. It works by peeking into the file cache
> > and check if there are any history pages present or accessed. In this
> > way it can detect almost all forms of sequential / semi-sequential read
> > patterns, e.g.
> >     - parallel / interleaved sequential scans on one file
> >     - sequential reads across file open/close
> >     - mixed sequential / random accesses
> >     - sparse / skimming sequential read
> >
> > It also have methods to detect some less common cases:
> >     - reading backward
> >     - seeking all over reading N pages
>
> Are there any ways to inform the kernel that you either are or aren't
> doing a sequential read? It seems that in some cases it would be better

This call will disable readahead totally for fd:
        posix_fadvise(fd, any, any, POSIX_FADV_RANDOM);

This one will reenable it:
        posix_fadvise(fd, any, any, POSIX_FADV_NORMAL);

This one will enable readahead _and_ set max readahead window to
2*max_readahead_kb:
        posix_fadvise(fd, any, any, POSIX_FADV_SEQUENTIAL);

> to bypass a bunch of tricky logic trying to determine that it's doing a
> sequential read. A sequential scan in PostgreSQL would be such a case.

You do not need to worry about the detecting `overhead' on sequential
scans :) The adaptive readahead framework has a fast code path(the
stateful method) to handle normal sequential reads, the detection of
which is really trivial.

> The opposite example would be an index scan of a highly uncorrelated
> index, which would produce mostly random reads from the table. In that
> case, reading ahead probably makes very little sense, though your logic
> might have a better idea of the access pattern than PostgreSQL does.

As for the index scans, the failsafe code path(i.e. the context based
one) will normally be used, and it does have a little overhead in
looking up the page cache(about 0.4% more CPU time). However, the
penalty of random disk access is so large that if ever it helps
reducing a small fraction of disk accesses, you wins.

Thanks,
Wu

В списке pgsql-performance по дате отправления:

Предыдущее
От: "Milen Kulev"
Дата:
Сообщение: Re: Quick Performance Poll
Следующее
От: Markus Schaber
Дата:
Сообщение: Re: Introducing a new linux readahead framework