Re: [HACKERS] [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZEto max_wal_send - Mailing list pgsql-hackers

From Jonathon Nelson
Subject Re: [HACKERS] [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZEto max_wal_send
Date
Msg-id CACJqAM3CHnDRhbi+LBw8NBHuGz91cW5BpA3ATDTCekt2uxPZFA@mail.gmail.com
Whole thread Raw
In response to [HACKERS] [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZE to max_wal_send  (Jonathon Nelson <jdnelson@dyn.com>)
Responses Re: [HACKERS] [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZEto max_wal_send  (Kevin Grittner <kgrittn@gmail.com>)
List pgsql-hackers


On Thu, Jan 5, 2017 at 1:01 PM, Andres Freund <andres@anarazel.de> wrote:
Hi,

On 2017-01-05 12:55:44 -0600, Jonathon Nelson wrote:
> Attached please find a patch for PostgreSQL 9.4 which changes the maximum
> amount of data that the wal sender will send at any point in time from the
> hard-coded value of 128KiB to a user-controllable value up to 16MiB. It has
> been primarily tested under 9.4 but there has been some testing with 9.5.
>
> In our lab environment and with a 16MiB setting, we saw substantially
> better network utilization (almost 2x!), primarily over high bandwidth
> delay product links.

That's a bit odd - shouldn't the OS network stack take care of this in
both cases?  I mean either is too big for TCP packets (including jumbo
frames).  What type of OS and network is involved here?

In our test lab, we make use of multiple flavors of Linux. No jumbo frames. We simulated anything from 0 to 160ms RTT (with varying degrees of jitter, packet loss, etc.) using tc. Even with everything fairly clean, at 80ms RTT there was a 2x improvement in performance.

--
Jon Nelson
Dyn / Principal Software Engineer

pgsql-hackers by date:

Previous
From: Kouhei Kaigai
Date:
Subject: [HACKERS] T_Float morph to T_Integer after nodeRead
Next
From: Jim Nasby
Date:
Subject: Re: [HACKERS] DROP FUNCTION of multiple functions