8.2. Особенности очистки на практике

всвою очередь,запускаетрабочий процесс autovacuum worker.Рабочий процесс очистки узнает имя целевой базы, подключается к ней и строит список таблиц, подлежащих обработке. Обрабатывая по очереди таблицы из списка, рабочий процесс сканирует их на предмет устаревших версий строк, не нужных ни одной из активных транзакций, и освобождает место как

всамих таблицах, так и в индексах. Освобожденное пространство может использоваться для вставкиновыхстрок.Есливходеочисткисвободноепространствообразовалосьвконцефайла таблицы,тоочисткаможетотсечьхвостовыепустыестраницы(truncateheap)итакимобразом уменьшить файл таблицы.

При некоторых видах рабочих нагрузок возникают случаи,когда втаблицах и индексах содержится относительно небольшое количество живых строк, а все остальное пространство освобождено и при этом не используется.Если при этом участки пустого пространства физически находятся в разных частях файла,то очистка не может высвободить эти участки и уменьшить сам файл.Процесс образования таких участков и их постепенное увеличение называют раздуванием (bloat). В самом безобидном случае следствием эффекта раздувания является впустую занимаемое пространство, а в худшем — снижение производительности ввода-вывода из-за избыточных операций, нехватки буферного кеша и снижения эффективности индексного доступа из-за образования лишних уровней у индексов. Поэтому при эксплуатации СУБД необходимо отслеживать излишнее раздувание таблиц и индексов и сокращать его.

Подводя некоторый итог,можно сказать,что с точки зрения эксплуатации администратор БД должен отслеживать эффективность работы автоочистки, создаваемый ею уровень нагрузки

идолю мертвых строк в таблицах, и при необходимости корректировать настройки очистки

иуменьшать образовавшееся раздувание.

В современных реалиях с ростом производительности систем хранения важность отслеживания уровня нагрузки от очистки сильно уменьшилась. Если раньше, в эпоху HDD-дисков, это было актуально, поскольку очистка могла значительно влиять на производительность запросов, то сейчас, при использовании SSD- и NVMe-носителей, это негативное влияние сильно уменьшилось или вообще сошло на нет.

8.2. Особенности очистки на практике

Чтобы получить представление о том, что именно следует отслеживать в работе очистки, давайте рассмотрим практические особенности ее работы. Очистка запускается только при наступлении определенных событий,и в идеале не должна запаздывать.Но в случае запаздывания важно представлять себе объем накопившейся работы.

Когда выполняется автоочистка?

Автоочистка обрабатывает таблицу, когда объем мертвых строк в ней превышает некоторое допустимое количество. Устаревшие версии строк появляются из-за обновлений и удалений;

198Глава 8. Очистка

при выполнении этих операций количество устаревших версий постоянно отслеживается, и, как только оно превыситдопустимое значение,таблица добавляется в список на обработку. Предельное значение вычисляется на основании следующей информации:

•pg_class.reltuples — общее количество строк в таблице согласно последнему выполнению очистки;

•pg_stat_all_tables.n_dead_tup — общее количество мертвых строк, которое обновляется при операциях обновления и удаления;

•autovacuum_vacuum_threshold — параметр, определяющий базовое пороговое значение, то есть минимальное количество мертвых строк в таблице, необходимое для ее очистки (по умолчанию 50 строк);

•autovacuum_vacuum_scale_factor — параметр, определяющий долю общего числа строк, на которую увеличивается базовое пороговое значение autovacuum_vacuum_threshold (по умолчанию 0,2,что означает 20% от pg_class.reltuples).

Согласно значениям по умолчанию, для срабатывания автоочистки количество мертвых строк в таблице должно превышать 50 + 20% от общего числа строк. Значение параметра autovacuum_vacuum_scale_factor = 0.2 часто воспринимается как консервативное и в современных конфигурациях принято указывать меньшее значение в диапазоне от 0,01 до 0,05, тем самым вызывая автоочистку чаще и при гораздо меньшем количестве мертвых строк. Для очень больших таблиц (с большими индексами) даже небольшое значение параметра autovacuum_vacuum_scale_factor припереводев строкиможетоказатьсябольшим,и рабочейпамяти может не хватитьдля размещения всех указателей на мертвые строки.Это очень сильно повышаетстоимостьпроцедурыочистки,таккакприэтомприходитсяполностьюсканировать иочищатьиндексынесколькораз.Втакихслучаяхдляотдельныхтаблицможноустанавливать индивидуальные параметры очистки с помощью параметров хранения1.

Теперь,знаяусловиесрабатыванияавтоочистки,можнонаписатьзапросдляопределениятаблиц, у которых количество мертвых строк превышает допустимое значение. Запрос выводит список пользовательских таблиц с некоторой статистикой:

•relation—имя таблицы.При желании можно вывести также имя схемы;

•reltuples—приблизительное количество строк втаблице.Это значение обновляется каждый раз после выполнения автоочистки,команд VACUUM,ANALYZE и некоторых DDL-команд вроде CREATE INDEX;

•live_tup—количество живых строк в таблице;

•dead_tup—количество устаревших,мертвых строк в таблице;

•boundary—допустимое количество мертвых версий строк.Когда количество мертвых версий превысит это значение,таблица должна обработаться автоочисткой;

•av_cnt—общее количество выполненных операций автоочистки на таблице;

•since_last_av—время,прошедшее с момента выполнения последней автоочистки;

1 postgrespro.ru/docs/postgresql/current/sql-createtable#SQL-CREATETABLE-STORAGE-PARAMETERS

•av_need—признактого,что количество мертвых версий превышаетдопустимое значение и таблице требуется обработка;

•dead_ratio — процентное отношение количества мертвых версий к общему числу строк в таблице.

#SELECT

По результатам запроса можно сделать несколько наблюдений:

•есть две таблицы (pgbench_tellers и pgbench_branches), которым требуется очистка: количество мертвых версий в них существенно превышает допустимое значение, о чем говорит признак av_need = t;

•значения av_cnt и since_last_av показывают, что две эти таблицы регулярно очищаются, ноприсложившейсярабочейнагрузкедоследующегозапускаочисткивтаблицахуспевает накопиться большое количество мертвых версий (см. dead_ratio);

•для оценки значения since_last_av важно знатьзначение параметра autovacuum_naptime1 (по умолчанию одна минута). Этот параметр определяет интервал, с которым процесс

1 postgrespro.ru/docs/postgresql/current/runtime-config-autovacuum#GUC-AUTOVACUUM-NAPTIME

autovacuum launcher отправляет сигнал на запуск рабочих процессов очистки в каждую базуданных.Ввыводезапросаестьдветаблицыспризнакомнеобходимостиочистки.Значенияsince_last_avдляэтихдвухтаблицукладываютсявминуту:этозначит,чтотаблицы хотьидолжны бытьобработаны,но задержки при этом нет.И наоборот,если бы при наличии признака очистки значение since_last_av превышало значение autovacuum_naptime, это указывало бы на то,что очистка опаздывает;

•есть таблица с большим количеством строк, которая при этом ни разу не подвергалась обработке (pgbench_accounts), поскольку объем мертвых строк ни разу не достигал порогового значения.

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

Дополнительно стоит отметить, как вычисляется допустимое значение (boundary). За основу берутсяобщиепараметрыконфигурации,однакоСУБДпредоставляетвозможностьуказывать эти параметры индивидуальнодля отдельныхтаблиц с помощьютак называемых параметров хранения (storage parameter)1.Они имеют приоритет перед общими параметрами конфигурации,иихследуетучитыватьприрасчетепороговогозначения.Втестовомокруженииутаблиц нет явно определенных параметров хранения,поэтому запрос их не учитывает.

Статистика выполнения очистки

В ранее рассмотренном запросе была использована функция pg_stat_get_autovacuum_count, которая возвращает количество обработок таблицы автоочисткой. Эта и еще несколько похожих функций используются в представлении pg_stat_all_tables, на котором также основаны представления pg_stat_user_tables и pg_stat_sys_tables.На основе этих функций в представленияхотображаютсянесколькополей,указывающихнаработукакавтоматической,такиручной очистки:

•last_vacuum—время,когда таблица в последний раз очищалась командой VACUUM;

•last_autovacuum—время,когда таблица в последний раз была обработана автоочисткой;

•vacuum_count—общее количество обработок таблицы командой VACUUM;

•autovacuum_count—общее количество обработок таблицы автоочисткой.

Сбор статистики для планировщика

Набор похожих полей естьидля операций сбора статистики планировщика.Сбор статистики можетвыполнятьсялибо с помощью вызова команды ANALYZE,либо какдополнительная операция при вызове команды VACUUM (с указанием параметра ANALYZE),либо рабочим процессом автоочистки.

1 postgrespro.ru/docs/postgresql/current/sql-createtable#SQL-CREATETABLE-STORAGE-PARAMETERS