[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