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

[Michael Renner]

> On 23 Aug 2015, at 03:24, Tatsuo Ishii <ishii at postgresql.org> wrote:
> 
>> This is corroborated in this graph: http://i.imgur.com/d0IafG0.png <http://i.imgur.com/d0IafG0.png>
>> 
>> It shows the average SQL query runtime of a PHP application without connection pooling - each request will create a new database connection.
>> 
>> mean_90 shows the truncated mean value after the top 10% of the query runtimes have been removed
>> upper_90 shows shows the 90th percentile of the query runtimes
> 
> It seems in the graph green line dropped from 2.0 to 1.0 at around
> 08/20 10PM. This is because you installed the patch?

It’s rather 10AM (see table on the right at https://en.wikipedia.org/wiki/12-hour_clock <https://en.wikipedia.org/wiki/12-hour_clock> - US time is confusing) - but yeah, that’s when we switched over to the patched pgpool version. 


> However unlike the previous patch all child process concurrently
> issues select(2) and will be woke up when an event arrives to file
> descriptors. So heavy context switch might happen.  But this might be
> over-thinking because even in the previous patch all the process that
> are waiting for acquiring sophomore are woke up when the holder of the
> semaphore release it anyway.


I think the semaphore implementation behaves differently. Looking at the return values of semop() [1] and the relevant chapters from TLPI [2], it’s suggested that semop() will block all but the winning process, resulting in no wakeups for all other children.

It might be best not to rely on connection-triggered select() wakeups but rather make semop-calls with timeouts so that the main child loop gets iterated on a regular basis. Alternatively alarm() in combination with a signal handler might be used as well.


best,
Michael


[1] http://linux.die.net/man/2/semop <http://linux.die.net/man/2/semop>

[2]
http://man7.org/tlpi/ <http://man7.org/tlpi/>
http://nopaste.narf.at/raw/26934/ <ttp://nopaste.narf.at/raw/26934/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.sraoss.jp/pipermail/pgpool-general/attachments/20150824/babb56c0/attachment.html>