Анализ влияния checkpoint_timeout на производительность СУБД PostgreSQL

[baldr]

SELECT MAX(aid) INTO max_i FROM pgbench_accounts ;
SELECT MIN(aid) INTO min_i FROM pgbench_accounts ;
current_aid = floor(random() * (max_i - min_i + 1)) + min_i ;
select br.bbalance
...

Classic... База сама себе генерирует нагрузку. Это мы уже видели во всех ваших статьях.

Снова вопрос на засыпку - сколько здесь запросов? И это вы гоняете в цикле. Так производительность которого из этих запросов вы меряете?

[OlegIct]

в предыдущей статье 15 минут были худшими «существует "резонансная зона" (около 15 мин), где наблюдаются наихудшие характеристики». В этой статье «оптимальным является значение 15 минут, которое обеспечивает наименьшую нагрузку на CPU при приемлемом использовании памяти»

Непонятно, почему взяли 15 минут, а не 20 минут.

При меньшем checkpoint_timeout вероятность записи полного образа одного и того же блока данных (full page image) в WAL выше. С другой стороны, пустота не пишется и размер записываемых данных тоже меньше. Оптимален интервал, при котором блоки зарисываются один раз, это и есть нижняя граница для chrckpoint_timeout

[pg_expecto]

в предыдущей статье 15 минут были худшими

в предыдущей статье

Анализ влияния checkpoint_timeout на производительность СУБД PostgreSQL при синтетической нагрузке(Вариант-1) / Хабр

был один профиль нагрузки . В этой статье эксперимент поставлен для двух разных профилей нагрузки.

почему взяли 15 минут, а не 20 минут.

В связи с политикой Хабра публикуются только выборочные , итоговые результаты экспериментов (1 публикация в неделю). На дзен-канале (ссылка в профиле) масса публикаций по другим значениям checkpoint_timeout. Я не буду приводить ссылку на подборку публикаций , во избежание дальнейшего непрерывного слива кармы по причине "Реклама", если интересно - ссылка на дзен в профиле. На репозиторий инструмента, кстати тоже, если интересно можно все эксперименты проводить и проверять самостоятельно.

В настоящее время эксперименты по checkpoint_timeout - завершены(ну по крайней мере приостановлены). Общая идея понятна, методика отработана, инструмент протестирован, поставленные цели экспериментов - достигнуты. Сейчас проводятся эксперименты по другой теме. Может быть также будет итоговая публикация. Если к тому времени карму не сольют до read-only ;-)

P.S. Ну и разумеется, если уж очень интересно обсуждение темы - лучше в личных сообщениях или в комментариях на дзене. Тут - цензура и отсутствие свободы слова. Впрочем это не бага , это фича Хабра.

[rSedoy]

Тут - цензура и отсутствие свободы слова. Впрочем это не бага , это фича Хабра.

нет, это просто реакция сообщества, на то что ты ведешь себя как спамер.

[pg_expecto]

это просто реакция сообщества, на то что ты ведешь себя как спамер

Ну и замечательно - ты сохранишь время , что бы не читать новые публикации по теме оптимизации производительности СУБД PostgreSQL , тем более тебе лично сказать сообществу по теме и нечего, кроме бессмысленных комментариев.

Я - использую время освободившееся от подготовки новых публикаций на Хабре на новые эксперименты и публикации на других ресурсах.

Сообщество - продолжить читать ленту Хабра про ИИ , HRов , менеджеров , психологов и прочих очень актуальных на техническом ресурсе материалов , наверное сообществу это очень интересно. Why not.

Администрация Хабра - передает просмотры и прочтения со своего ресурса, другим.

И все довольны . И это хорошо.