Re: LWLock contention: I think I understand the problem

Tom Lane wrote:

>I have gotten my hands on a Linux 4-way SMP box (courtesy of my new
>employer Red Hat), and have obtained pgbench results that look much
>more promising than Tatsuo's. It seems the question is not so much
>"why is 7.2 bad?" as "why is it bad on AIX?"
>
Could you rerun some of the tests on the same hardware but with
uniprocesor kernel
to get another reference point ?

There were some reports about very poor insert performance on 4way vs 1way
processors.

You could also try timing pgbench -i to compare raw inser performance.

>The test machine has 4 550MHz Pentium III CPUs, 5Gb RAM, and a passel
>of SCSI disks hanging off ultra-wide controllers. It's presently
>running Red Hat 7.1 enterprise release, kernel version 2.4.2-2enterprise
>#1 SMP. (Not the latest thing, but perhaps representative of what
>people are running in production situations. I can get it rebooted with
>other kernel versions if anyone thinks the results will be interesting.)
>
>
>For the tests, the postmasters were started with parameters
> postmaster -F -N 100 -B 3800
>(the -B setting chosen to fit within 32Mb, which is the shmmax setting
>on stock Linux). -F is not very representative of production use,
>but I thought it was appropriate since we are trying to measure CPU
>effects not disk I/O. pgbench scale factor is 50; xacts/client varied
>so that each run executes 10000 transactions, per this script:
>
>#! /bin/sh
>
>DB=bench
>totxacts=10000
>
>for c in 1 2 3 4 5 6 10 25 50 100
>do
> t=`expr $totxacts / $c`
> psql -c 'vacuum' $DB
>
Should this not be 'vacuum full' ?

>
> psql -c 'checkpoint' $DB
> echo "===== sync ======" 1>&2
> sync;sync;sync;sleep 10
> echo $c concurrent users... 1>&2
> pgbench -n -t $t -c $c $DB
>done
>
-----------
Hannu