From: | Curt Sampson <cjs(at)cynic(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | nickf(at)ontko(dot)com, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Ray Ontko <rayo(at)ontko(dot)com> |
Subject: | Re: Script to compute random page cost |
Date: | 2002-09-10 04:19:46 |
Message-ID: | Pine.NEB.4.44.0209101302540.13186-100000@angelic.cynic.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 9 Sep 2002, Tom Lane wrote:
> Curt Sampson <cjs(at)cynic(dot)net> writes:
> > On Mon, 9 Sep 2002, Tom Lane wrote:
> >> ... We are trying to measure the behavior when kernel
> >> caching is not helpful; if the database fits in RAM then you are just
> >> naturally going to get random_page_cost close to 1, because the kernel
> >> will avoid doing any I/O at all.
>
> > Um...yeah; another reason to use randread against a raw disk device.
> > (A little hard to use on linux systems, I bet, but works fine on
> > BSD systems.)
>
> Umm... not really; surely randread wouldn't know anything about
> read-ahead logic?
Randread doesn't know anything about read-ahead logic, but I don't
see how that matters one way or the other. The chances of it reading
blocks sequentially are pretty much infinitesimal if you're reading
across a reasonably large area of disk (I recommend at least 4GB),
so readahead will never be triggered.
> The reason this is a difficult topic is that we are trying to measure
> certain kernel behaviors --- namely readahead for sequential reads ---
> and not others --- namely caching, because we have other parameters
> of the cost models that purport to deal with that.
Well, for the sequential reads, the readahead should be trigerred
even when reading from a raw device. So just use dd to measure
that. If you want to slightly more accurately model postgres'
behaviour, you probably want to pick a random area of the disk,
read a gigabyte, switch areas, read another gigabyte, and so on.
This will model the "split into 1GB" files thing.
cjs
--
Curt Sampson <cjs(at)cynic(dot)net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2002-09-10 04:51:12 | Re: Optimization levels when compiling PostgreSQL... |
Previous Message | Tom Lane | 2002-09-10 03:43:08 | Re: Script to compute random page cost |