Re: [PERFORM] Comparing postgresql7.4 CVS head on linux 2.4.20 and 2.6.0-test4

2003-08-28 Thread Shridhar Daithankar
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.


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [PERFORM] Comparing postgresql7.4 CVS head on linux 2.4.20 and 2.6.0-test4

2003-08-27 Thread Neil Conway
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


---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings