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

Re: ProcArrayLock (The Saga continues)

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Jignesh K(dot) Shah" <J(dot)K(dot)Shah(at)Sun(dot)COM>
Cc: "Postgresql Performance" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: ProcArrayLock (The Saga continues)
Date: 2008-05-30 00:19:11
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
"Jignesh K. Shah" <J(dot)K(dot)Shah(at)Sun(dot)COM> writes:

> Note with this no think time concept, each clients can be about 75% CPU busy
> from what I observed. running it I found the clients scaling up saturates at
> about 60  now (compared to 500 from the original test). The peak throughput was
> at about 50 users (using synchrnous_commit=off)

So to get the maximum throughput on the benchmark with think times you want to
aggregate the clients about 10:1 with a connection pooler or some middleware
layer of some kind, it seems.

It's still interesting to find the choke points for large numbers of
connections. But I think not because it's limiting your benchmark results --
that would be better addressed by using fewer connections -- just for the sake
of knowing where problems loom on the horizon.

  Gregory Stark
  Ask me about EnterpriseDB's PostGIS support!

In response to

pgsql-performance by date

Next:From: Vlad ArkhipovDate: 2008-05-30 11:02:41
Subject: Statistics issue
Previous:From: Jignesh K. ShahDate: 2008-05-29 22:08:10
Subject: ProcArrayLock (The Saga continues)

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