On Wed, Aug 27, 2003 at 09:02:25PM +0530, Shridhar Daithankar wrote:
> IIRC in a kernel release note recently, it was commented that IO scheduler is
> still being worked on and does not perform as much for random seeks, which
> exaclty what database needs.
Yeah, I've read that as well. It would be interesting to see how 2.6
performs with the traditional (non-anticipatory) scheduler -- I believe
you can switch from one I/O scheduler to another via a sysctl.
> pgbench -c10 -t100 test1
> tps = 64.917044 (including connections establishing)
> tps = 65.438067 (excluding connections establishing)
Interesting that the performance of 2.4.20 for this particular
benchmark is a little less than 3 times faster than 2.6
> 3) Shared buffers 3000
>
> pgbench -c5 -t100 test
> tps = 132.489569 (including connections establishing)
> tps = 135.177003 (excluding connections establishing)
>
> pgbench -c5 -t1000 test
> tps = 70.272855 (including connections establishing)
> tps = 70.343452 (excluding connections establishing)
>
> pgbench -c10 -t100 test
> tps = 121.624524 (including connections establishing)
> tps = 123.549086 (excluding connections establishing)
[...]
> 4) noatime enabled Shared buffers 3000
>
> pgbench -c5 -t100 test
> tps = 90.850600 (including connections establishing)
> tps = 92.053686 (excluding connections establishing)
>
> pgbench -c5 -t1000 test
> tps = 92.209724 (including connections establishing)
> tps = 92.329682 (excluding connections establishing)
>
> pgbench -c10 -t100 test
> tps = 79.264231 (including connections establishing)
> tps = 80.145448 (excluding connections establishing)
I'm a little skeptical of the consistency of these numbers
(several people have observed in the past that it's difficult
to get pgbench to produce reliable results) -- how is it
possible that using noatime can possibly *reduce* performance
by 50%, in the case of the first and third benchmarks?
-Neil