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