Skip site navigation (1) Skip section navigation (2)

Re: LWLock contention: I think I understand the problem

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
Cc: pgman(at)candle(dot)pha(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org, jwbaker(at)acm(dot)org
Subject: Re: LWLock contention: I think I understand the problem
Date: 2002-01-04 23:13:59
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-odbc
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?"

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


for c in 1 2 3 4 5 6 10 25 50 100
        t=`expr $totxacts / $c`
        psql -c 'vacuum' $DB
        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

The results are shown in the attached plot.  Interesting, hmm?
The "sweet spot" at 3 processes might be explained by assuming that
pgbench itself chews up the fourth CPU.

This still leaves me undecided whether to apply the first or second
version of the LWLock patch.

			regards, tom lane

Attachment: bench4way.gif
Description: image/gif (6.6 KB) (inlined above)

In response to


pgsql-hackers by date

Next:From: Matthew KirkwoodDate: 2002-01-05 00:27:50
Subject: Re: O_DIRECT use
Previous:From: Bruce MomjianDate: 2002-01-04 23:13:56
Subject: Re: O_DIRECT use

pgsql-odbc by date

Next:From: Simeo ReigDate: 2002-01-04 23:34:57
Subject: Re: Sending lot of records
Previous:From: Simeo ReigDate: 2002-01-04 22:29:00
Subject: Sending lot of records

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group