Greg Stark <gsstark@MIT.EDU> writes:
> However I wonder about another approach entirely. If postgres timed how long
> reads took it shouldn't find it very hard to distinguish between a cached
> buffer being copied and an actual i/o operation. It should be able to track
> the percentage of time that buffers requested are in the kernel's cache and
> use that directly instead of the estimated cache size.
I tested this with a program that times seeking to random locations in a file.
It's pretty easy to spot the break point. There are very few fetches that take
between 50us and 1700us, probably they come from the drive's onboard cache.
The 1700us bound probably would be lower for high end server equipment with
10k RPM drives and RAID arrays. But I doubt it will ever come close to the
100us edge, not without features like cache ram that Postgres would be better
off considering to be part of "effective_cache" anyways.
So I would suggest using something like 100us as the threshold for determining
whether a buffer fetch came from cache.
Here are two graphs, one showing a nice curve showing how disk seek times are
distributed. It's neat to look at for that alone:
This is the 1000 fastest data points zoomed to the range under 1800us:
This is the program I wrote to test this:
Here are the commands I used to generate the graphs:
$ dd bs=1M count=1024 if=/dev/urandom of=/tmp/big
$ ./a.out 10000 /tmp/big > /tmp/l
$ gnuplot
gnuplot> set terminal png
gnuplot> set output "/tmp/plot1.png"
gnuplot> plot '/tmp/l2' with points pointtype 1 pointsize 1
gnuplot> set output "/tmp/plot2.png"
gnuplot> plot [0:2000] [0:1000] '/tmp/l2' with points pointtype 1 pointsize 1
--
greg
