From: Yura Sokolov <y.sokolov@postgrespro.ru>
To: Andres Freund <andres@anarazel.de>
Cc: rony.kurniawan@oracle.com
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17005: Enhancement request: Improve walsender throughput by aggregating multiple messages in one send
Date: Mon, 17 May 2021 16:21:36 +0300
Message-ID: <aae9709fddecd6f6b59405c62a861dae@postgrespro.ru> (raw)
In-Reply-To: <20210516224413.xitbilinlyrlt42m@alap3.anarazel.de>
References: <17005-3e1030784d5440c4@postgresql.org>
<20210516224413.xitbilinlyrlt42m@alap3.anarazel.de>
Andres Freund писал 2021-05-17 01:44:
> Hi,
>
> On 2021-05-13 00:31:53 +0000, PG Bug reporting form wrote:
>> I measured the throughput of reading the logical replication slot and
>> found
>> that in smaller row size (512 bytes) the throughput is 50% lower
>> compared to
>> 1024 bytes.
>
> Huh, that is interesting.
>
>
>> tcpdump shows that ethernet packets sent by the replication server
>> contain
>> only one message per packet (see tcpdump output below).
>> May be this is the intended design to achieve low latency but this is
>> not
>> favorable in application that requires high throughput.
>
> What kind of network is this? I would have expected that if the network
> can't keep up the small sends would end up getting aggregated into
> larger packets anyway? Are you hitting a PPS limit due to the small
> packages, but not yet the throughput limit?
I believe the reason is more in sys-call and kernel cpu time overhead
than in
network throughput. Especially in this "after meltdown+spectre" time.
>
>> Is it possible for PostgreSQL to enable Nagle's algorithm on the
>> streaming
>> socket for replication?
>> Or aggegate the messages manually before sending them in one send()?
>
> I think we can probably do better in cases a transaction is more than a
> single change - but I don't think either enabling nagle's or
> aggregation
> are really an option in case of single row transactions. The latency
> impact for some scenarios seems too high.
We have commit_siblings and commit_delay options. Probably similar could
be introduced for replication slot?
regards
Yura
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: y.sokolov@postgrespro.ru, andres@anarazel.de, rony.kurniawan@oracle.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17005: Enhancement request: Improve walsender throughput by aggregating multiple messages in one send
In-Reply-To: <aae9709fddecd6f6b59405c62a861dae@postgrespro.ru>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox