<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 23 Aug 2015, at 03:24, Tatsuo Ishii <<a href="mailto:ishii@postgresql.org" class="">ishii@postgresql.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" class="">This is corroborated in this graph: <a href="http://i.imgur.com/d0IafG0.png" class="">http://i.imgur.com/d0IafG0.png</a> <<a href="http://i.imgur.com/d0IafG0.png" class="">http://i.imgur.com/d0IafG0.png</a>><br class=""><br class="">It shows the average SQL query runtime of a PHP application without connection pooling - each request will create a new database connection.<br class=""><br class="">mean_90 shows the truncated mean value after the top 10% of the query runtimes have been removed<br class="">upper_90 shows shows the 90th percentile of the query runtimes<br class=""></blockquote><br class="">It seems in the graph green line dropped from 2.0 to 1.0 at around<br class="">08/20 10PM. This is because you installed the patch?<br class=""></div></blockquote><div><br class=""></div>It’s rather 10AM (see table on the right at <a href="https://en.wikipedia.org/wiki/12-hour_clock" class="">https://en.wikipedia.org/wiki/12-hour_clock</a> - US time is confusing) - but yeah, that’s when we switched over to the patched pgpool version. <br class=""><div><br class=""></div></div><div><br class=""><blockquote type="cite" class=""><div class="">However unlike the previous patch all child process concurrently<br class="">issues select(2) and will be woke up when an event arrives to file<br class="">descriptors. So heavy context switch might happen. But this might be<br class="">over-thinking because even in the previous patch all the process that<br class="">are waiting for acquiring sophomore are woke up when the holder of the<br class="">semaphore release it anyway.<br class=""></div></blockquote></div><div><br class=""></div><div>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.</div><div><br class=""></div><div>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.</div><div><br class=""></div><div><br class=""></div><div>best,</div><div>Michael</div><div><br class=""></div><div><br class=""></div><div>[1] <a href="http://linux.die.net/man/2/semop" class="">http://linux.die.net/man/2/semop</a></div><div><br class=""></div><div>[2]</div><div><a href="http://man7.org/tlpi/" class="">http://man7.org/tlpi/</a></div><div><a href="ttp://nopaste.narf.at/raw/26934/" class="">http://nopaste.narf.at/raw/26934/</a></div></body></html>