From: Jignesh K. Shah <J.K.Shah@Sun.COM>
To: Scott Carey <scott@richrelevance.com>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: Proposal of tunable fix for scalability of 8.4
Date: Fri, 13 Mar 2009 14:48:33 -0400
Message-ID: <49BAAA81.2080408@sun.com> (raw)
In-Reply-To: <C5DFEA86.342D%scott@richrelevance.com>
References: <C5DFEA86.342D%scott@richrelevance.com>
Somebody else asked a question: This is actually a two socket machine
(128) threads but one socket is disabled by the OS so only 64-threads
are available... The idea being let me choke one socket first with 100%
CPU ..
> Forgot some data: with the second test above, CPU: 48% user, 18% sys,
> 35% idle. CPU increased from 46% used in the first test to 65% used,
> the corresponding throughput increase was not as large, but that is
> expected on an 8-threads per core server since memory bandwidth and
> cache resources at a minimum are shared and only trivial tasks can
> scale 100%.
>
> Based on the above, I would guess that attaining closer to 100%
> utilization (its hard to get past 90% with that many cores no matter
> what), will probablyl give another 10 to 15% improvement at most, to
> maybe 180000/min throughput.
>
> Its also rather interesting that the 2000 connection case with wait
> times gets 170000/min throughput and beats the 328 users with 0 delay
> result above. I suspect the ‘wake all’ version is just faster. I would
> love to see a ‘wake all shared, leave exclusives at front of queue’
> version, since that would not allow lock starvation.
Considering that there is one link list it is just easier to wake the
sequential selected few or wake them all up.. If I go through the list
trying to wake all the shared ones then I essentially need to have
another link list to collect all the exclusives ...
I will retry the thundering herd of waking all waiters irrespective of
shared, exclusive and see how that behaves.. I think the biggest benefit
is when the process is waked up and the process in reality is already on
the cpu checking the field to see whether last guy who released the lock
is allowing him to wake up or not.
Still I will try some more experiments.. Definitely reducing time in
"Waiting" lock waits benefits and making "Acquired" times more efficient
results in more tpm per user.
I will try another run with plain wake up all and see with the same
parameters (0 think time) that test behaves..
-Jignesh
--
Jignesh Shah http://blogs.sun.com/jkshah
The New Sun Microsystems,Inc http://sun.com/postgresql
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: J.K.Shah@Sun.COM, scott@richrelevance.com
Subject: Re: Proposal of tunable fix for scalability of 8.4
In-Reply-To: <49BAAA81.2080408@sun.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox