Re: [resent PATCH] Re: very slow parallel read performance

Daniel Phillips
2001-08-26T21:00:41Z

On August 26, 2001 09:18 pm, pcg@goof.com ( Marc) (A.) (Lehmann ) wrote:
> On Sun, Aug 26, 2001 at 07:29:43PM +0200, Daniel Phillips wrote:

> > > Now, a question: how does the per-block-device read-ahead fit into
> > > this picture? Is it being ignored? I fiddled with it (under
> > > 2.4.8pre4) but couldn't see any difference.
> >
> > It should not be being ignored. This needs to be looked into.
>
> so the efefctive read-ahead is 2min(per-block-device, kernel-global)"? if
> yes, then this would be ideal for my case, as usage patterns are strictly
> seperated by disk in the machine, so I could get the best of all worlds.

Yes.

> > tree, otherwise changing the default MAX_READAHEAD requires a recompile.
>
> I like the proposed ideas of making it autotune ;) I think very large
> readaheads make a lot of sense under normal loads with modern harddisks,
> but not always.

Well, autotuning will require some r&d, plus a settling in period. In the
meantime it's quite safe and useful to use a user-set global as you showed,
and also will be helpful during the development of the automagic version.

> [...]
> Also, this whole thread was very fruitfull for that server:
>
> 929 (929) connections
> 4084385150 bytes written in the last 1044.23861896992 seconds
> (3911352.3 bytes/s)
>
> which is almost twice as fast as with my old setup/config. Thanks to all
> who analyzed it, sent patches and gave hints (thttpd gave about 700kb/s
> on the same setup, with only 250 connections, but admittedly only 4k
> read-requests).

To recap, you made these changes:

- Changed to -ac
- Set max-readahead through proc

Anything else? Did you change MAX_SECTORS?

> I believe that, with some tweaking (more memory dedicated to buffers), I
> could go to 4.5 and maybe 5mb/s, but certainly not much higher. And it's
> no longer thrashing. And linux does the job nicely ;)

Good, but should we rest on our laurels now?

--
Daniel