<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 07 Aug 2015, at 02:10, Tatsuo Ishii <<a href="mailto:ishii@postgresql.org" class="">ishii@postgresql.org</a>> wrote:</div></blockquote><blockquote type="cite" class=""><div class=""><blockquote type="cite" class="">Do you have any plans to implement an event- or lock-based approach in pgpool?<br class=""></blockquote><br class="">Long time ago I played with accept+semaphores approach to see if<br class="">there's any performance improvement. The result was not positive and I<br class="">gave up the approach. Unfortunately nor test code or test data remain<br class="">though.<br class=""></div></blockquote></div><br class=""><div class=""><br class=""></div><div class="">I’d be surprised if you don’t see performance problems on todays hardware with medium load. Here’s numbers from our environment.</div><div class=""><br class=""></div><div class="">We’ve got three pgpool nodes, next to pgpool there’s also a mongodb config server running there, doing very little work.</div><div class=""><br class=""></div><div class="">Each server has two Intel Xeon E5-2430 v2, 6 cores @ 2.50GHz and 16GB of 1333MHz DDR3 RAM - fairly recent hardware and not the slowest to boot with.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Here’s a vmstat -w 1 output from an idle node: </div><div class=""><br class=""></div><div class=""><a href="http://nopaste.narf.at/show/25530/" class="">http://nopaste.narf.at/show/25530/</a></div><div class=""><br class=""></div><div class="">About 5000 context switches/sec, not nice but not bad either.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Here’s the same command from the node running the active pgpool instance:</div><div class=""><br class=""></div><div class=""><a href="http://nopaste.narf.at/show/25531/" class="">http://nopaste.narf.at/show/25531/</a></div><div class=""><br class=""></div><div class="">About ~400.000 context switches/second - about 60% of _ALL_ available CPU time is spent in the kernel.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">tcpdump shows a connection rate of about 350 connections/sec: <a href="http://nopaste.narf.at/show/25533/" class="">http://nopaste.narf.at/show/25533/</a></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">stracing a single pgpool process shows the wakeups due to the unfenced select/accept loop: <a href="http://nopaste.narf.at/show/25527/" class="">http://nopaste.narf.at/show/25527/</a></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><a href="http://nopaste.narf.at/show/jPt7GaDbsRLCxZKhKu9y/" class="">http://nopaste.narf.at/show/jPt7GaDbsRLCxZKhKu9y/</a> is the configuration we run with, relevant settings:</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class="">connection_cache = on</div>num_init_children = 1500</div><div class="">max_pool = 1</div><div class="">child_life_time = 300</div><div class="">child_max_connections = 2000</div><div class="">connection_life_time = 0</div><div class="">client_idle_limit = 600</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">So if there’s nothing horribly wrong/out of the ordinary with our setup, I’d pretty much say that with a high number of children fencing around select/accept is dearly needed.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">best,</div><div class="">Michael</div></body></html>