Skip site navigation (1) Skip section navigation (2)

Re: Effects of setting linux block device readahead size

From: "Scott Carey" <scott(at)richrelevance(dot)com>
To: "Greg Smith" <gsmith(at)gregsmith(dot)com>
Cc: "Mark Wong" <markwkm(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>, "Gabrielle Roth" <gorthx(at)gmail(dot)com>, "Selena Deckelmann" <selenamarie(at)gmail(dot)com>
Subject: Re: Effects of setting linux block device readahead size
Date: 2008-09-10 16:26:25
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
How does that readahead tunable affect random reads or mixed random /
sequential situations?  In many databases, the worst case scenarios aren't
when you have a bunch of concurrent sequential scans but when there is
enough random read/write concurrently to slow the whole thing down to a
crawl.   How the file system behaves under this sort of concurrency

I would be very interested in a mixed fio profile with a "background writer"
doing moderate, paced random and sequential writes combined with concurrent
sequential reads and random reads.


On Wed, Sep 10, 2008 at 7:49 AM, Greg Smith <gsmith(at)gregsmith(dot)com> wrote:

> On Tue, 9 Sep 2008, Mark Wong wrote:
>  I've started to display the effects of changing the Linux block device
>> readahead buffer to the sequential read performance using fio.
> Ah ha, told you that was your missing tunable.  I'd really like to see the
> whole table of one disk numbers re-run when you get a chance.  The reversed
> ratio there on ext2 (59MB read/92MB write) was what tipped me off that
> something wasn't quite right initially, and until that's fixed it's hard to
> analyze the rest.
> Based on your initial data, I'd say that the two useful read-ahead settings
> for this system are 1024KB (conservative but a big improvement) and 8192KB
> (point of diminishing returns).  The one-disk table you've got (labeled with
> what the default read-ahead is) and new tables at those two values would
> really flesh out what each disk is capable of.
> --
> * Greg Smith gsmith(at)gregsmith(dot)com Baltimore, MD
> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
> To make changes to your subscription:

In response to


pgsql-performance by date

Next:From: Ryan HansenDate: 2008-09-10 16:48:41
Subject: Improve COPY performance for large data sets
Previous:From: Kevin GrittnerDate: 2008-09-10 14:58:45
Subject: Re: too many clog files

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group