Re: Reduce ProcArrayLock contention

On 08/07/2015 02:03 PM, Andres Freund wrote:
>>> 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.
>

Confirmed.

Running w/o -P x and the problem goes away.

Thanks !

Best regards, Jesper