[pgpool-hackers: 3235] Re: pgbench: Flamegraph
Jesper Pedersen
jesper.pedersen at redhat.com
Fri Feb 8 03:41:38 JST 2019
Hi,
On 2/7/19 1:25 AM, Tatsuo Ishii wrote:
> Here's an another attempt to enhance Pgpool-II performance in
> extended query + streaming replication case. The idea is to minimize
> the necessity to call pool_flush(), which in turn calls write(2) to
> the frontend socket. Attached is the patch and quick result of
> pgbench. In pgbench -S case, I got up to 10.6% improvement over stock
> master branch HEAD.
>
Confirmed. Overall with the two patches I see ~17% improvement compared
to master.
Ideally, we should only see
__libc_write: Writing to the socket
__libc_read : Reading from the socket
__select : Waiting on data
The numbers in the attached profile says
__libc_write: 52.4%
__libc_read : 5.1%
__select : 18.0%
-------------------
Total: 75.5%
But, two things pop out of that.
1) Low % of reads
2) __select within pool_read()
If you look at per_node_error_message() again you will see that it spend
almost the same amount of time in pool_check_fd() (should that function
be moved to pool_stream.c ?) as it does in the actual read() call. (For
some reason the __libc_read and __select entries are next to the actual
function call.)
select() has a big overhead, as noted in
https://beej.us/guide/bgnet/html/single/bgnet.html#select
but I'm moving my work load to other machines with 10Gbpe network in
order to do more testing; currently increasing the read buffer size had
no effect.
Best regards,
Jesper
-------------- next part --------------
A non-text attachment was scrubbed...
Name: prepared_patched12-master.svg
Type: image/svg+xml
Size: 1037743 bytes
Desc: not available
URL: <http://www.sraoss.jp/pipermail/pgpool-hackers/attachments/20190207/cb05d5e9/attachment-0001.svg>
More information about the pgpool-hackers
mailing list