Re: [PATCH 00/33] Adaptive read-ahead V12

Nick Piggin
2006-05-26T03:14:12Z

Jon Smirl wrote:

> On 5/25/06, Andrew Morton <akpm@osdl.org> wrote:
>
>> These are nice-looking numbers, but one wonders. If optimising
>> readahead
>> makes this much difference to postgresql performance then postgresql
>> should
>> be doing the readahead itself, rather than relying upon the kernel's
>> ability to guess what the application will be doing in the future.
>> Because
>> surely the database can do a better job of that than the kernel.
>>
>> That would involve using posix_fadvise(POSIX_FADV_RANDOM) to disable
>> kernel
>> readahead and then using posix_fadvise(POSIX_FADV_WILLNEED) to launch
>> application-level readahead.
>
>
> Users have also reported that this patch fixes performance problems
> from web servers using sendfile(). In the case of lighttpd they
> actually stopped using sendfile() for large transfers and wrote a user
> space replacement where they could control readahead manually. With
> this patch in place sendfile() went back to being faster than the user
> space implementation.

Of course, that is something one would expect should be made to work
properly
with the current readahead implementation.

I don't see Wu's patches getting in for a little while yet.

Reproducable test cases (preferably without a whole lot of network clients)
should get this proble fixed.

--

Send instant messages to your online friends http://au.messenger.yahoo.com