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

[Tatsuo Ishii]

>> 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.
> 
> Thanks for the suggestion. Let me see how I can implement in other way
> using semtimedop().

So far I have created a patch using semtimedop().

It shows very good performance for connection establishing to
pgpool-II. Unfortunately it slows down in terms of TPS.

I have tested with "pgbench -S -p 11000 -c 32 -C -S -T 10 test" with
num_init_children = 400. PostgreSQL is 9.4.4 and there's only 1
PostgreSQL node. pgpool-II and PostgreSQL are running on same Linux
box using UNIX domain socket.

Here is the TPS from 3.3 stable head.
tps = 718.150625 (including connections establishing)
tps = 22368.793929 (excluding connections establishing)

Here is the TPS from 3.4.2.
tps = 694.075467 (including connections establishing)
tps = 20661.230806 (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 :-<

I have run out my time on this and hope someone comes up and points
out what is wrong with my patch.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: accept_lock_v3_rev2.patch
Type: text/x-patch
Size: 7571 bytes
Desc: not available
URL: <http://www.sraoss.jp/pipermail/pgpool-general/attachments/20150825/5b011207/attachment.bin>