[pgpool-general: 4002] Re: accept() scalability issues
ishii at postgresql.org
Tue Aug 25 16:51:34 JST 2015
>> 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.
SRA OSS, Inc. Japan
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7571 bytes
Desc: not available
More information about the pgpool-general