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 http://www.gregsmith.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 Hansen||Date: 2008-09-10 16:48:41|
|Subject: Improve COPY performance for large data sets|
|Previous:||From: Kevin Grittner||Date: 2008-09-10 14:58:45|
|Subject: Re: too many clog files|