Re: [SPAM?] Re: Asynchronous I/O Support

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: [SPAM?] Re: Asynchronous I/O Support
Дата
Msg-id b42b73150610201752v58317a4x49ad2409a4d8c6d4@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [SPAM?] Re: Asynchronous I/O Support  (Martijn van Oosterhout <kleptog@svana.org>)
Список pgsql-hackers
On 10/21/06, Martijn van Oosterhout <kleptog@svana.org> wrote:
> On Fri, Oct 20, 2006 at 03:04:55PM -0400, Merlin Moncure wrote:
> > On 10/20/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > >So far I've seen no evidence that async I/O would help us, only a lot
> > >of wishful thinking.
> >
> > is this thread moot?  while researching this thread I came across this
> > article: http://kerneltrap.org/node/6642 describing claims of 30%
> > performance boost when using posix_fadvise to ask the o/s to prefetch
> > data.  istm that this kind of improvement is in line with what aio can
> > provide, and posix_fadvise is cleaner, not requiring threads and such.
>
> Hmm, my man page says:
>
>        POSIX_FADV_WILLNEED and POSIX_FADV_NOREUSE both initiate a
>        non-blocking read of the specified region into the page cache.
>        The amount of data read may be decreased by the kernel depending
>        on VM load. (A few megabytes will usually be fully satisfied,
>        and more is rarely useful.)
>
> This appears to be exactly what we want, no? It would be nice to get
> some idea of what systems support this.

right, and a small clarification: the above claim of 30% was from
using adaptive readahead, not posix_fadvise.  posix_fadvise was
suggested by none other than andrew morton as the way to get the most
i/o out of your box.  there was no mention of aio :)

merlin


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

Предыдущее
От: "Tux P"
Дата:
Сообщение: PgSQL users quota
Следующее
От: Neil Conway
Дата:
Сообщение: Re: adminpack and pg_catalog