[pgpool-general: 4003] Re: accept() scalability issues

[Michael Renner]

> On 25 Aug 2015, at 09:51, Tatsuo Ishii <ishii at postgresql.org> wrote:
>> Thanks for the suggestion. Let me see how I can implement in other way
>> using semtimedop().

> Here is the TPS from 3.3 stable head.
> tps = 718.150625 (including connections establishing)
> tps = 22368.793929 (excluding connections establishing)
> 
> So connection included TPS is ~700, connection excluded TPS is ~20000.
> 
> Here is the TPS from modified 3.3 stable (patch attached).
> tps = 1999.094538 (including connections establishing)
> tps = 13345.641707 (excluding connections establishing)
> 
> So connection included TPS is very good.  However connection time
> excluded TPS is very low :-<


Just to clarify, the difference between the runs including connection establishing and without is the “--connect” parameter to pgbench?


Seeing that your patch only modifies the code flow only for the accept loop, I see two options what could cause the slowdowns for the bench run using persistent connections.

 * Wakeups from timeouting children

Only 32 of the 400 children are used, in the past all the other children would block on select() and not wakeup, causing an undisturbed benchmark run. If ~360 children need to be woken up to complete their accept loop this might be a sufficient large interruption to affect the measurement

What was the setting of child_life_time?


* Load on the server

Seeing that you only did 10 seconds of benchmarking it could entirely be possible that something else interfered with your measurement.


best,
Michael