Re: [HACKERS] [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZEto max_wal_send

Поиск
Список
Период
Сортировка
От Jonathon Nelson
Тема Re: [HACKERS] [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZEto max_wal_send
Дата
Msg-id CACJqAM3CHnDRhbi+LBw8NBHuGz91cW5BpA3ATDTCekt2uxPZFA@mail.gmail.com
обсуждение исходный текст
Ответ на [HACKERS] [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZE to max_wal_send  (Jonathon Nelson <jdnelson@dyn.com>)
Ответы Re: [HACKERS] [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZEto max_wal_send  (Kevin Grittner <kgrittn@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Kouhei Kaigai
Дата:
Сообщение: [HACKERS] T_Float morph to T_Integer after nodeRead
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: [HACKERS] DROP FUNCTION of multiple functions