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
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
