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

Re: Multiprocessor performance

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Valentin Puente <vpuente(at)atc(dot)unican(dot)es>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Multiprocessor performance
Date: 2001-06-05 15:37:23
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Valentin Puente wrote:
> Hi all,
> I'm not a postgres hacker, but I' think that you must be the most
> appropriate person to give me a pointer about this question.... sorry for
> any possible mistake.
> Now I'm trying to use postgresql plus the pgbench like a
> first test to stress the interconnection system in a parallel machine. I
> know that tpc-b is just a toy (no too much real... but before to do
> something more complex like tpc-c y want to see the postgres behavior).
> Ok...well I'm running this benchmarks in different SMP machines (SGI with 4
> to 8 processors and the results are odd). The best performance is achieved
> with just one backend (1 client). When I try to run more clients the tps
> falls quickly.
> In all cases I see that when I increase the number of clients the total CPU
> usage falls. With one client I can see a 100% usage (after a warm-up to get
> all data from disk - I'm running without fsync and with a large shared
> buffer).My systems have a lot of memory then this is normal. But when I try
> with more clients each CPU usage falls between 40% for 2 clients to 10% to 8
> clients. I assume the access to the shared memory through critical regions
> (lock-unlock) must be one reason... but this is too much. I've heard that
> locks in postgress are at page level instead tuple level. I'm wrong?.
> Some suggestion about this?.

    What was the scaling factor on pgbench initialization? if you
    used the 1-default, your bottleneck is the single row in  the
    branches table, which everyone wants to lock for update. Try

        pgbench -i -s <10 or higher> <dbname>

    to give it a kick.



# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck(at)Yahoo(dot)com #

Do You Yahoo!?
Get your free address at

In response to

pgsql-hackers by date

Next:From: Stephan SzaboDate: 2001-06-05 15:38:08
Subject: RE: Imperfect solutions
Previous:From: Oleg BartunovDate: 2001-06-05 15:02:00
Subject: Re: Strange query plan

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