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: 200106051537.f55FbNe01609@jupiter.us.greatbridge.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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.

Jan

--

#======================================================================#
# 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 @yahoo.com address at http://mail.yahoo.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephan Szabo 2001-06-05 15:38:08 RE: Imperfect solutions
Previous Message Oleg Bartunov 2001-06-05 15:02:00 Re: Strange query plan