Re: [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZE to max_wal_send

From: Jonathon Nelson <jdnelson(at)dyn(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZE to max_wal_send
Date: 2017-01-06 01:32:13
Message-ID: CACJqAM3CHnDRhbi+LBw8NBHuGz91cW5BpA3ATDTCekt2uxPZFA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jan 5, 2017 at 1:01 PM, Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2017-01-06 01:37:24 Re: DROP FUNCTION of multiple functions
Previous Message Kouhei Kaigai 2017-01-06 01:31:26 T_Float morph to T_Integer after nodeRead