Обсуждение: Comparing postgresql7.4 CVS head on linux 2.4.20 and 2.6.0-test4

Hi all,

I did some benchmarking using pgbench and postgresql CVS head, compiled
yesterday.

The results are attached. It looks like 2.6.0-test4 does better under load but
under light load the performance isn't that great. OTOH 2.4.20 suffer major
degradation compare to 2.6. Looks like linux is also getting heavy at lower
end. Of course it isn't as bad as solaris as yet..:-)

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.

How does these number stack up with other platforms? Anybody with SCSI disks
out there? I doubt IDE has some role to play with this.

Comments?

 Shridhar

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

On 27 Aug 2003 at 19:00, Neil Conway wrote:

> 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.

I will repeat the tests after get that setting. Will google for it..

>
> > 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

Yeah but 2.4 drops like anything..
> > 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?

I know. I am puzzled too. Probably I didn't put noatime properly in /etc/fstab.
Unfortunately I have only one linux partition. So I prefer to boot rather than
remounting root.

I will redo the bechmarks and post the results..

Bye
 Shridhar

--
Law of Communications:    The inevitable result of improved and enlarged
communications    between different levels in a hierarchy is a vastly increased
area of misunderstanding.