Cached file read performance with 6.2-PRERELEASE

[Pieter de Goeje]

On Wednesday 20 December 2006 22:20, Mark Kirkwood wrote:
> Pieter de Goeje wrote:
> > On Wednesday 20 December 2006 11:38, Mark Kirkwood wrote:
> >> In fact if you note that the PIII HW *can* actually do 700MB/s, it
> >> suggests that your HW is capable of considerably more than 900MB/s -
> >> given that opteron's have excellent cpu to memory bandwidth, and the
> >> speed of your memory!
> >
> > Indeed!
> > Copying /dev/zero to /dev/null yields more than 5GB/sec on a simple 2Ghz
> > Athlon64. It imagine there are quite a few extra things done when copying

On second thought, this is wrong because /dev/zero isn't a real block of 
memory so these results say nothing about memory I/O speed because all data 
is in (cpu) cache.

> > a file from cache, because I can only manage to get one fifth (~1GB/sec)
> > of the theoretical speed. (this is with a file that fills more than half
> > of all memory)
> >
> > Note that linux seems to play tricks (zero copy?) when doing dd
> > if=/dev/zero of=/dev/null, because you can reach speeds which are way
> > above the theoretical maximum. (30GB/sec on a P4 1,6Ghz ??? no way)
> >
> > In the context of databases, I think the speeds are limited by the
> > processing done on the data, as long as the read speed stays above a
> > certain limit.
>
> Yeah - typically it is creating tuples out of the blocks/pages just
> read, so for a big memory scan CPU appears to be the limiting factor!
>
> > It would be more interesting to see how random access to a (cached) file
> > performs in Linux vs FreeBSD, which seems a more logical pattern for a
> > database.
>
> Agreed, and good point, I'll knock up a simple program to do random
> and/or sequential access of a file and see what we get!
I'll check 'em out :)

Cheers,
Pieter