Thread: Linux 2.2 vs 2.4

Hi,

Not sure if anyone will find this of interest, but I ran
pgbench on my main Linux box to see what sort of performance
difference might be visible between 2.2 and 2.4 kernels.

Hardware: A dual P3-450 with 384Mb of RAM and 3 SCSI disks.
The pg datafiles live in a half-gig partition on the first
one.

Software: Red Hat 6.1 plus all sort of bits and pieces.
PostgreSQL 7.1beta4 RPMs.  pgbench hand-compiled from source
for same.  No options changed from defaults.  (I'll look at
that tomorrow -- is there anything worth changing other than
commit_delay and fsync?)

Kernels: 2.2.15 + software RAID patches, 2.4.2-pre2

With 2.2.15:pgbench -s5 -i: 1.27.78 elapsedpgbench -s5 -t100:clients: TPS / TPS (excluding connection establishment)1:
39.66/ 40.08 TPS2: 60.77 / 61.64 TPS4: 76.15 / 77.428: 90.99 / 92.7316: 71.10 / 72.1532: 49.20 / 49.701: 27.76 /
28.001:27.82 / 28.03
 
pgbench -v -s5 -t100:1: 30.73 / 30.98


And with 2.4.2-pre2:pgbench -s5 -i: 1:17.46 elapsedpgbench -s5 -t1001: 43.57 / 44.11 TPS2: 62.85 / 63.86 TPS4: 87.24 /
89.08TPS8: 86.60 / 88.38 TPS16: 53.22 / 53.88 TPS32: 60.28 / 61.10 TPS1: 35.93 / 36.331: 34.82 / 35.18
 
pgbench -v -s5 -t100:1: 35.70 / 36.01


Overall, two things jump out at me.

Firstly, it looks like 2.4 is mixed news for heavy pgbench users
:)  Low-utilisation numbers are better, but the sweet spot seems
lower and narrower.

Secondly, in both occasions after a run, performance has been
more than 20% lower.  Restarting or performing a full vacuum does
not seem to help.  Is there some sort of fragmentation issue
here?

Matthew.

Matthew Kirkwood <matthew@hairy.beasts.org> writes:
> No options changed from defaults.  (I'll look at
> that tomorrow -- is there anything worth changing other than
> commit_delay and fsync?)

-B for sure ... the default -B is way too small for WAL.

> Firstly, it looks like 2.4 is mixed news for heavy pgbench users
> :)  Low-utilisation numbers are better, but the sweet spot seems
> lower and narrower.

Huh?  With the exception of the 16-user case (possibly measurement
noise), 2.4 looks better across the board, AFAICS.  But see below.

> Secondly, in both occasions after a run, performance has been
> more than 20% lower.

I find that pgbench's reported performance can vary quite a bit from run
to run, at least with smaller values of total transactions.  I think
this is because it's a bit of a crapshoot how many WAL logfile
initializations occur during the run and get charged against the total
time.  Not to mention whatever else the machine might be doing.  With
longer runs (say at least 10000 total transactions) the numbers should
stabilize.  I wouldn't put any faith at all in tests involving less
than about 1000 total transactions...
        regards, tom lane

On Sat, 17 Feb 2001, Tom Lane wrote:

> the default -B is way too small for WAL.

OK, here are some 2.4 numbers with 1K transactions/client
and -B10240.

> Huh?  With the exception of the 16-user case (possibly measurement
> noise), 2.4 looks better across the board, AFAICS.  But see below.

OK.

Rough methodology:
# service postgresql stop
# rpm -e postgresql-server
# rm -fr /var/lib/pgsql
# service postgresql start
# reboot
# sysctl -w kernel.shmmax=186048768
pg$ creatuser matthew
pg$ createdb matthew
me$ ./pgbench -i -s5 -t$T -c$N

Does this look fairly immune to troubles?

> > Secondly, in both occasions after a run, performance has been
> > more than 20% lower.
>
> I find that pgbench's reported performance can vary quite a bit from
> run to run, at least with smaller values of total transactions.  I
> think this is because it's a bit of a crapshoot how many WAL logfile
> initializations occur during the run and get charged against the total
> time.  Not to mention whatever else the machine might be doing.  With
> longer runs (say at least 10000 total transactions) the numbers should
> stabilize.  I wouldn't put any faith at all in tests involving less
> than about 1000 total transactions...

Ah, good point.  Here are some with 2.4.2pre2 and 1000 transactions.

I'll try to find time tomorrow to do some batch benching with 10K
transactions on various kernels.

I hear allegations that the 2.4.1 disk elevator and VM are subject
to investigation to I'll try to keep some up-to-date numbers if any-
one is interested.

Matthew.

-- 
Numbers:
2.4.2-pre2 (-B10240):
pgbench -s5 -i: 1:13:02 elapsedpgbench -s5 -t10001: 40.06 / 40.10 TPS2: 53.01 / 53.084: 57.14 / 57.238: 62.82 /
62.9216:62.46 / 62.5632: 43.15 / 43.201: 23.48 / 26.051: 30.85 / 30.88
 
pgbench -v -s5 -t10001: 26.37 / 26.39