Re: checkpointer continuous flushing - V16

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: checkpointer continuous flushing - V16
Дата
Msg-id alpine.DEB.2.10.1602191554320.3927@sto
обсуждение исходный текст
Ответ на Re: checkpointer continuous flushing - V16  (Andres Freund <andres@anarazel.de>)
Ответы Re: checkpointer continuous flushing - V16  (Patric Bechtel <patric.bechtel@gmail.com>)
Список pgsql-hackers
Hello.

> Based on these results I think 32 will be a good default for
> checkpoint_flush_after? There's a few cases where 64 showed to be
> beneficial, and some where 32 is better. I've seen 64 perform a bit
> better in some cases here, but the differences were not too big.

Yes, these many runs show that 32 is basically as good or better than 64.

I'll do some runs with 16/48 to have some more data.

> I gather that you didn't play with 
> backend_flush_after/bgwriter_flush_after, i.e. you left them at their 
> default values? Especially backend_flush_after can have a significant 
> positive and negative performance impact.

Indeed, non reported configuration options have their default values. 
There were also minor changes in the default options for logging (prefix, 
checkpoint, ...), but nothing significant, and always the same for all 
runs.

>>  [...] Ubuntu 12.04 LTS (precise)
>
> That's with 12.04's standard kernel?

Yes.

>>    checkpoint_flush_after = { none, 0, 32, 64 }
>
> Did you re-initdb between the runs?

Yes, all runs are from scratch (initdb, pgbench -i, some warmup...).

> I've seen massively varying performance differences due to autovacuum
> triggered analyzes. It's not completely deterministic when those run,
> and on bigger scale clusters analyze can take ages, while holding a
> snapshot.

Yes, I agree that probably the performance changes on long vs short runs 
(andres00c vs andres00b) is due to autovacuum.

-- 
Fabien.



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

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: Relaxing SSL key permission checks
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: pg_ctl promote wait