[pgpool-hackers: 3247] Re: select(2) storm

[Tatsuo Ishii]

> Hi,
> 
> As noted in [1] 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
developers).

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...

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: eliminate-select.diff
Type: text/x-patch
Size: 8597 bytes
Desc: not available
URL: <http://www.sraoss.jp/pipermail/pgpool-hackers/attachments/20190220/558214d7/attachment.bin>