Re: WAL insert delay settings

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: WAL insert delay settings
Дата
Msg-id 2CE20460-C983-4873-8AB7-F7ED817E13FE@anarazel.de
обсуждение исходный текст
Ответ на Re: WAL insert delay settings  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Ответы Re: WAL insert delay settings  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Список pgsql-hackers

On February 14, 2019 10:31:57 AM GMT+01:00, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote:
>
>
>On 2/14/19 10:06 AM, Andres Freund wrote:
>> Hi,
>>
>> On 2019-02-14 10:00:38 +0100, Tomas Vondra wrote:
>>> On 2/13/19 4:31 PM, Stephen Frost wrote:
>>>> Greetings,
>>>>
>>>> * Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:
>>>>> Bulk operations like CREATE INDEX, ALTER TABLE, or bulk loads can
>create
>>>>> a lot of WAL.  A lot of WAL at once can cause delays in
>replication.
>>>>
>>>> Agreed, though I think VACUUM should certainly be included in this.
>>>>
>>>
>>> Won't these two throttling criteria interact in undesirable and/or
>>> unpredictable way? With the regular vacuum throttling (based on
>>> hit/miss/dirty) it's possible to compute rough read/write I/O
>limits.
>>> But with the additional sleeps based on amount-of-WAL, we may sleep
>for
>>> one of two reasons, so we may not reach either limit. No?
>>
>> Well, it'd be max rates for either, if done right. I think we only
>> should start adding delays for WAL logging if we're exceeding the WAL
>> write rate.
>
>Not really, I think. If you add additional sleep() calls somewhere,
>that
>may affect the limits in vacuum, making it throttle before reaching the
>derived throughput limits.

I don't understand. Obviously, if you have two limits, the scarcer resource can limit full use of the other resource.
Thatseems OK? The thing u think we need to be careful about is not to limit in a way, e.g. by adding sleeps even when
belowthe limit, that a WAL limit causes throttling of normal IO before the WAL limit is reached. 


>> That's obviously more complicated than the stuff we do for
>> the current VACUUM throttling, but I can't see two such systems
>> interacting well. Also, the current logic just doesn't work well when
>> you consider IO actually taking time, and/or process scheduling
>effects
>> on busy systems.
>>
>
>True, but making it even less predictable is hardly an improvement.

I don't quite see the problem here. Could you expand?

Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: WAL insert delay settings
Следующее
От: Etsuro Fujita
Дата:
Сообщение: Re: Problems with plan estimates in postgres_fdw