[pgpool-hackers: 3247] Re: select(2) storm
ishii at sraoss.co.jp
Wed Feb 20 10:33:26 JST 2019
> As noted in  a big percentage of the run-time is spent in
> select(2), which is known to have a performance overhead.
> Attached is a "proxy" which replicates the scenario where pool_read*()
> calls pool_check_fd() showing the select(2) issue.
Attached is a patch trying eliminate calls to pool_check_fd() (the
same one I sent to you privately. I just wanted to share with other
The idea is checking select(2) timeout parameter set in a static
variable in pool_read() and pool_read2(). If it's -1, it means no
select timeout will be set in pool_check_fd(), which implies we can
avoid to call pool_check_fd().
Also I moved pool_check_fd() and friends to pool_stream.c from a
modularity point of view.
I heard from you that the patch did no performance improvement. I am
thinking about it and came to an idea; even if we avoid to call
pool_check_fd(), subsequent read(2) has to wait for packets from
frontend or backend. So the total time for processing has not been
changed by the patch. Of course this is just my guess. I need a proof
of the theory...
SRA OSS, Inc. Japan
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 8597 bytes
Desc: not available
More information about the pgpool-hackers