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
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 |