Влияние vacuum/analyze/bloat на производительность СУБД

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Задачи эксперимента

1) Оценить степень влияния регулярного выполнения vacuum/analyze на производительность СУБД.

2) Оценить степень влияния распухания таблицы на производительность СУБД.

Реализация эксперимента

Одна итерация теста состоит из транзакции select/insert/update/delete ( количество строк в таблицах ~1 000 000 ) .

Количество итераций = 1000.

Оцениваемые параметры

  1. Общее время выполнения ( total_exec_time представления pg_stat_statements)

  2. Количество запросов ( calls представления pg_stat_statements )

  3. Количество результирующих строк ( rows представления pg_stat_statements )

  4. Общее число прочитанных разделяемых блоков ( shared_blks_read представления pg_stat_statements )

  5. Общее число "загрязнённых" разделяемых блоков ( shared_blk_dirtied представления pg_stat_statements )

  6. Общее число записанных разделяемых блоков ( shared_blk_written представления pg_stat_statements )

  7. Количество транзакций ( xact_commit представления pg_stat_database )

  8. Метрика производительности СУБД ( CPI )

Результаты эксперимента

Эталонный тест - vacuum + analyze после каждой итерации

Рис.1. Базовая нагрузка
Рис.1. Базовая нагрузка

Тест без выполнения vacuum + analyze после каждой итерации

Рис.2. Тест без vacuum+analyze
Рис.2. Тест без vacuum+analyze

Сравнение результатов с "Эталонный тест - vacuum + analyze после каждой итерации"

  • Время выполнения теста - незначительно уменьшилось

  • Объем обработанных разделяемых блоков - значительно увеличился

  • Производительность - существенно уменьшилась

Фрагментация 11%

Рис.3. Фрагментация 11%
Рис.3. Фрагментация 11%

Сравнение результатов с "Тест без выполнения vacuum + analyze после каждой итерации"

  • Время выполнения теста - существенно увеличилось

  • Объем обработанных разделяемых блоков - существенно увеличился

  • Производительность - существенно уменьшилась

Фрагментация 100%

Рис.4. Фрагментация 100%
Рис.4. Фрагментация 100%

Сравнение результатов с "Тест без выполнения vacuum + analyze после каждой итерации"

  • Время выполнения теста - существенно увеличилось

  • Объем обработанных разделяемых блоков - существенно увеличился

  • Производительность - существенно уменьшилась

Итоги

Выполнение vacuum+analyze после массовых изменений данных существенно увеличивает производительность СУБД, хотя общее время выполнения и несколько возрастает.

Даже относительно небольшая фрагментация оказывает существенное влияние на производительность СУБД.

Дальнейшее увеличение фрагментации не оказывает заметного влияния на производительность СУБД.

Источник: https://habr.com/ru/articles/845454/


Интересные статьи

Интересные статьи

В этой статье мы рассмотрим, как управляющие ИТ-активами могут продлить срок службы своих активов, и стать ведущими участниками организации экономики замкнутого цикла в ИТ.
Три года назад у одного из наших заказчиков — крупнейшего российского банка — появилась задача перенастроить платёжный сервис для ГИС ГМП (штрафы, пошлины и налоги), ГИС ЖКХ, а также запросы начислени...
Привет, дорогой читатель! В этой статье я хочу затронуть тему, которая в IT-сообществе и так хорошо известна а кому-то может даже и поднадоела, но поговорить о которой все же хочется по ...
Нередко вижу слова в духе «по другим отраслям коронавирус сильно ударил, а вот IT практически не затронул». Мол, веб-сервисы от карантина только выиграли, писать код можно и удалённ...
«Движение это жизнь», — сказала крыша и уехала. Эта шутка довольно «бородатая», но, как и в любой шутке, в ней также есть доля истины. Ведь действительно большинство животных на планете имеют...