Re: Reduce ProcArrayLock contention

Hi,

On 2015-08-07 19:30:46 +0200, Andres Freund wrote:
> On 2015-08-07 12:49:20 -0400, Jesper Pedersen wrote:
> > No, this patch helps on performance - there is an improvement in numbers
> > between
> >
> > http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=253de7e1eb9abbcf57e6c229a8a38abd6455c7de
> >
> > and
> >
> > http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=0e141c0fbb211bdd23783afa731e3eef95c9ad7a
> >
> > but you will have to use a 9.5 pgbench to see it, especially with higher
> > client counts.

Hm, you were using -P X, is that right?

> This bisects down to 1bc90f7a7b7441a88e2c6d4a0e9b6f9c1499ad30 - "Remove
> thread-emulation support from pgbench."

And the apparent reason seems to be that too much code has been removed
in that commit:

@@ -3650,11 +3631,7 @@ threadRun(void *arg)
}

/* also wake up to print the next progress report on time */
- if (progress && min_usec > 0
-#if !defined(PTHREAD_FORK_EMULATION)
- && thread->tid == 0
-#endif /* !PTHREAD_FORK_EMULATION */
- )
+ if (progress && min_usec > 0)
{
/* get current time if needed */
if (now_usec == 0)
@@ -3710,7 +3687,7 @@ threadRun(void *arg)

This causes all threads but thread 0 (i.e. the primary process) to busy
loop around select: min_usec will be set to 0 once the first progress
report interval has been reached:
if (now_usec >= next_report)
min_usec = 0;
else if ((next_report - now_usec) < min_usec)
min_usec = next_report - now_usec;

but since we never actually print the progress interval in any thread
but the the main process that's always true from then on:

/* progress report by thread 0 for all threads */
if (progress && thread->tid == 0)
{
...
/*
* Ensure that the next report is in the future, in case
* pgbench/postgres got stuck somewhere.
*/
do
{
next_report += (int64) progress *1000000;
} while (now >= next_report);

Hrmpf.

Andres