hi all
I've just upgraded to 2.4.16 to get /proc/sys/vm/(max|min)-readahead
available. I've got this idea...
If lots of files (some hundered) are read simultaously, I waste all the
i/o time in seeks. However, if I increase the readahead, it'll read more
data at a time, and end up with seeking a lot less.
The harddrive I'm testing this with, is a cheap 20G IDE drive. It can give
me a peak thoughput of about 28 MB/s (reading).
When running 10 simultanous dd jobs ('dd if=filenr of=/dev/null bs=4m'), I
peaks at some 8,5 MB/s no matter what I set the min/max readahead to!!
Is this correct?
Is there perhaps another way to set the real readahead? In source???
Thanks a lot for all help
roy
--
Roy Sigurd Karlsbakk, MCSE, MCNE, CLS, LCA
Computers are like air conditioners.
They stop working when you open Windows.
On Wed, 5 Dec 2001, Roy Sigurd Karlsbakk wrote:
> hi all
>
> I've just upgraded to 2.4.16 to get /proc/sys/vm/(max|min)-readahead
> available. I've got this idea...
>
> If lots of files (some hundered) are read simultaously, I waste all the
> i/o time in seeks. However, if I increase the readahead, it'll read more
> data at a time, and end up with seeking a lot less.
>
> The harddrive I'm testing this with, is a cheap 20G IDE drive. It can give
> me a peak thoughput of about 28 MB/s (reading).
> When running 10 simultanous dd jobs ('dd if=filenr of=/dev/null bs=4m'), I
> peaks at some 8,5 MB/s no matter what I set the min/max readahead to!!
>
> Is this correct?
Do you also have VM pressure going on or do you have lots of free memory ?
> Do you also have VM pressure going on or do you have lots of free memory ?
I've got a lot of memory (some 380 megs), but what is VM pressure?
--
Roy Sigurd Karlsbakk, MCSE, MCNE, CLS, LCA
Computers are like air conditioners.
They stop working when you open Windows.
On Wed, 5 Dec 2001, Roy Sigurd Karlsbakk wrote:
> > Do you also have VM pressure going on or do you have lots of free memory ?
>
> I've got a lot of memory (some 380 megs), but what is VM pressure?
VM pressure means that there is not enough free memory on the system...
Allocators have to reclaim memory.
Basically you cannot simply expect an increase in readahead size to
increase performance:
1) The files you created may not be sequential
2) The lack of memory on the system may be interfering in weird ways, and
maybe _INCREASING_ the readahead may decrease performance.
...
Also, remember: The real applications running on the system may not want
to read files sequentially, so increasing readahead is just useless.
> > I've got a lot of memory (some 380 megs), but what is VM pressure?
>
> VM pressure means that there is not enough free memory on the system...
> Allocators have to reclaim memory.
There's more than enough memory on the system, as far as I can see
[root@linuxserver ext2]# free
total used free shared buffers cached
Mem: 381500 378136 3364 0 3552 333348
-/+ buffers/cache: 41236 340264
Swap: 522104 11440 510664
> Basically you cannot simply expect an increase in readahead size to
> increase performance:
>
> 1) The files you created may not be sequential
Beleive me - they are! Created with 'dd' secuentially
> 2) The lack of memory on the system may be interfering in weird ways, and
> maybe _INCREASING_ the readahead may decrease performance.
Anyway - I beleive I should have seen some change by trying virtually any
value from 31 to 4095.
If the readahead is what I beleive it is, It'll read further out in the
file when a request comes. It looks like either this never happens, or the
next request doesn't 'know' how much is cached.
roy
--
Roy Sigurd Karlsbakk, MCSE, MCNE, CLS, LCA
Computers are like air conditioners.
They stop working when you open Windows.
On Wed, 5 Dec 2001, Marcelo Tosatti wrote:
> On Wed, 5 Dec 2001, Roy Sigurd Karlsbakk wrote:
>
> > I've just upgraded to 2.4.16 to get /proc/sys/vm/(max|min)-readahead
> > available. I've got this idea...
> >
> > If lots of files (some hundered) are read simultaously, I waste all the
> > i/o time in seeks. However, if I increase the readahead, it'll read more
> > data at a time, and end up with seeking a lot less.
>
> Do you also have VM pressure going on or do you have lots of free memory ?
I suspect the per-device readahead for IDE is limiting the
effect of vm_max_readahead ...
Rik
--
Shortwave goes a long way: irc.starchat.net #swl
http://www.surriel.com/ http://distro.conectiva.com/
> I suspect the per-device readahead for IDE is limiting the
> effect of vm_max_readahead ...
hm...
any way to avoid this? I mean... The readahead in vm is layered above the
actual device, and should therefore not be limited... Am I right? You
could do several device calls, and fake readahead, and probably get pretty
much out of it.
--
Roy Sigurd Karlsbakk, MCSE, MCNE, CLS, LCA
Computers are like air conditioners.
They stop working when you open Windows.
> > Basically you cannot simply expect an increase in readahead size to
> > increase performance:
> >
> > 1) The files you created may not be sequential
>
> Beleive me - they are! Created with 'dd' secuentially
thats still does not mean they are sequential creating
large files almost always causes them to fragment.
Actually does anyone know of an easy way to find out
if certin files are fragmented and by how much ?
> thats still does not mean they are sequential creating
> large files almost always causes them to fragment.
ok...
mkfs /dev/hdb1
dd if=/dev/zero of=some-file bs=x count=x
What can fragment this file????
after that - wget http://localhost/some-file - watch vmstat, and find it's
pushing data at around 28 MB/s
then - start ten wget's retrieving different files, and watch vmstat,
finding the maximum thoughput I can get is ~ 10 MB/s - almost one third.
If I could tell the kernel, the app (tux) or whatever, to do readahead -
say some 4 megs per file, it'd work like hell! Seeks are reduced to a
minimum and everyone's happy again
> Actually does anyone know of an easy way to find out
> if certin files are fragmented and by how much ?
I beleive there used to be a utility called 'frag' or something, to check
the fragmentation of files
roy
--
Roy Sigurd Karlsbakk, MCSE, MCNE, CLS, LCA
Computers are like air conditioners.
They stop working when you open Windows.
Roy Sigurd Karlsbakk wrote:
>
> hi all
>
> I've just upgraded to 2.4.16 to get /proc/sys/vm/(max|min)-readahead
> available. I've got this idea...
>
> If lots of files (some hundered) are read simultaously, I waste all the
> i/o time in seeks. However, if I increase the readahead, it'll read more
> data at a time, and end up with seeking a lot less.
>
> The harddrive I'm testing this with, is a cheap 20G IDE drive.
/proc/sys/vm/*-readhead is a no-op for IDE. It doesn't do
anything. You must use
echo file_readahead:100 > /proc/ide/ide0/hda/settings
to set the readhead to 100 pages (409600 bytes).
-
> > thats still does not mean they are sequential creating
> > large files almost always causes them to fragment.
>
> ok...
> mkfs /dev/hdb1
> dd if=/dev/zero of=some-file bs=x count=x
>
> What can fragment this file????
say you wanna write a 500MB file
on a disk with plenty of space.
but when you create the file it happens to
create it in a place that only a 50MB file can
fit because there is another file on the disk in that
position. after 50MB is created then you have to put the rest file
elsewhere thus you now have a fragmented file.
James
On Wednesday 05 December 2001 21:13, Andrew Morton wrote:
> Roy Sigurd Karlsbakk wrote:
> > hi all
> >
> > I've just upgraded to 2.4.16 to get /proc/sys/vm/(max|min)-readahead
> > available. I've got this idea...
> >
> > If lots of files (some hundered) are read simultaously, I waste all the
> > i/o time in seeks. However, if I increase the readahead, it'll read more
> > data at a time, and end up with seeking a lot less.
> >
> > The harddrive I'm testing this with, is a cheap 20G IDE drive.
>
> /proc/sys/vm/*-readhead is a no-op for IDE. It doesn't do
> anything. You must use
>
> echo file_readahead:100 > /proc/ide/ide0/hda/settings
>
> to set the readhead to 100 pages (409600 bytes).
Make that kB!
(page sizes is an implementation detail that depends on architecture,
compilation options...)
(for Andrew:
it multiplies with 1024 then divides by PAGE_SIZE, result is in pages.
If you wanted to set no of pages then the scaling should be *1/1...
earlier it only multiplied with 1024...)
/RogerL
--
Roger Larsson
Skellefte?
Sweden
Roy Sigurd Karlsbakk wrote:
>
> > I suspect the per-device readahead for IDE is limiting the
> > effect of vm_max_readahead ...
>
> hm...
>
> any way to avoid this? I mean... The readahead in vm is layered above the
> actual device, and should therefore not be limited... Am I right? You
> could do several device calls, and fake readahead, and probably get pretty
> much out of it.
He means the hardware device read ahead, which can be changed by using
hdparm -a 32 -A1 /dev/hda
for example.
The value of the read ahead one layer on top of it
(read_ahead array) can't have *any* impact on performance.
Thanks!
It works
On Wed, 5 Dec 2001, Andrew Morton wrote:
> Roy Sigurd Karlsbakk wrote:
> >
> > hi all
> >
> > I've just upgraded to 2.4.16 to get /proc/sys/vm/(max|min)-readahead
> > available. I've got this idea...
> >
> > If lots of files (some hundered) are read simultaously, I waste all the
> > i/o time in seeks. However, if I increase the readahead, it'll read more
> > data at a time, and end up with seeking a lot less.
> >
> > The harddrive I'm testing this with, is a cheap 20G IDE drive.
>
> /proc/sys/vm/*-readhead is a no-op for IDE. It doesn't do
> anything. You must use
>
> echo file_readahead:100 > /proc/ide/ide0/hda/settings
>
> to set the readhead to 100 pages (409600 bytes).
>
> -
>
--
Roy Sigurd Karlsbakk, MCSE, MCNE, CLS, LCA
Computers are like air conditioners.
They stop working when you open Windows.
> > mkfs /dev/hdb1
> > dd if=/dev/zero of=some-file bs=x count=x
> >
> > What can fragment this file????
> say you wanna write a 500MB file
> on a disk with plenty of space.
>
> but when you create the file it happens to
> create it in a place that only a 50MB file can
> fit because there is another file on the disk in that
> position. after 50MB is created then you have to put the rest file
> elsewhere thus you now have a fragmented file.
er...
take a look above
mkfs /dev/hdb1
(mount /dev/hdb1 /some/dir)
dd if=/dev/zero of=/some/dir/file ...
--
Roy Sigurd Karlsbakk, MCSE, MCNE, CLS, LCA
Computers are like air conditioners.
They stop working when you open Windows.
In article <[email protected]> you wrote:
>> mkfs /dev/hdb1
>> dd if=/dev/zero of=some-file bs=x count=x
>> What can fragment this file????
> say you wanna write a 500MB file
...
> fit because there is another file on the disk
it is not, he just reformated the disk
In article <[email protected]> you wrote:
> It works
what results do you get?
>> echo file_readahead:100 > /proc/ide/ide0/hda/settings
Greetings
Bernd
> > It works
>
> what results do you get?
>
> >> echo file_readahead:100 > /proc/ide/ide0/hda/settings
echo file_readahead:1024 > /proc/ide/ide0/hda/settings
...gave me full throughput to the disk (this disk can do ~25MB/s) while
reading 50 files concurrently :-)
--
Roy Sigurd Karlsbakk, MCSE, MCNE, CLS, LCA
Computers are like air conditioners.
They stop working when you open Windows.