Глава 9
Ход выполнения операций
Вэтой главе мы рассмотрим:
•инструменты для отслеживания выполнения команд;
•отслеживание сбора статистики для планировщика;
•отслеживание хода выполнения резервного копирования;
•отслеживание выполнения команд CLUSTER и VACUUM FULL;
•отслеживание выполнения команд CREATE INDEX и REINDEX;
•отслеживание выполнения команд COPY.
Вэтой главе мы рассмотрим отдельный набор системных представлений, которые служат индикаторами выполнения различных команд, работа которых может занимать продолжительное время.Выполнениетаких команд можеттребовать значительных ресурсов,создавать нагрузку (например, на подсистему ввода-вывода), конкурировать с соседними процессами и даже блокировать их. Предполагая подобные риски, администратор должен заранее планировать выполнение таких операций и иметь инструменты, которые позволяют отслеживать ход их выполнения и давать представление о том, когда они будут завершены. Все инструменты, рассматриваемые в этой главе, являются представлениями и показывают состояние на момент обращения аналогично pg_stat_activity и pg_locks.Эта статистика требуется в основном в особых случаях, возникающих при эксплуатации, и может выводиться в пользовательских интерфейсах средств управления PostgreSQL. В меньшей степени она подходит для накопления и отображения в системах мониторинга.
Несмотря на большое количество потенциально долгих команд, СУБД представляет инструменты отслеживания только небольшой части из них:
•pg_stat_progress_vacuum—выполнение операций очистки и автоочистки;
•pg_stat_progress_analyze—выполнение сбора статистики для планировщика;
•pg_stat_progress_basebackup—выполнение операций резервного копирования;
•pg_stat_progress_cluster—выполнение команд CLUSTER и VACUUM FULL;
•pg_stat_progress_create_index—выполнение команд CREATE INDEX и REINDEX;
•pg_stat_progress_copy—выполнение команд COPY.
Представление pg_stat_progress_vacuum подробно рассмотрено в главе 8,посвященной очистке,поэтому здесь мы не будем рассматривать его снова.
222Глава 9. Ход выполнения операций
Все представления показывают выполняющиеся команды, которые обычно запускаются при необходимости вручную (за исключением автоочистки). Также вероятно, что в последующих версиях СУБД будет расширяться поддержка команд и будут появляться новые похожие представления.
9.1. Представление pg_stat_progress_analyze
При исполнении запроса СУБД следует наиболее оптимальному с точки зрения использования ресурсов плану выполнения,выбранному планировщиком из множества возможных планов. Для оценки планов используется статистика, описывающая данные, хранящиеся в таблицах, и от ее точности зависит качество выбранного плана. Собираемая статистика отражается в системном представлении pg_stats1, основанном на таблице pg_statistic2. В процессе эксплуатации СУБД количественные и качественные характеристики данных могут и будут меняться, и статистика планировщика в pg_statistics будет неизбежно устаревать. В условиях изменяющихся данных очень важно регулярно обновлять статистику: в противном случае выбираемые на основе устаревшей информации планы будутнеэффективными,что приведет к избыточному использованию ресурсов и увеличению времени выполнения.
Статистика обычно собирается рабочими процессами автоочистки,но у администратора есть возможностьзапуститьсбор принудительно (с помощью команды ANALYZE3 или VACUUM) илибо дождаться его окончания,либо оценить,сколько времени он займет.
Это может понадобиться в разных ситуациях:
•после восстановления из логической резервной копии (сделанной с помощью pg_dump) или после загрузки данных с помощью команды COPY нужно собрать начальную статистику,поскольку ее не существовало вообще;
•после изменения параметра default_statistics_target4, который ограничивает объем анализируемых и собираемых данных;
•прежде чем начинать глубже исследовать проблему производительности отдельного запроса с помощью EXPLAIN5,можно предварительно убедиться,что статистика актуальна;
•после обновления версии СУБД с помощью утилиты pg_upgrade6, поскольку при такой процедуре статистика планировщика не переносится.
Возможны и другие сценарии, но в любом случае процесс сбора статистики может занимать продолжительное время и администратору следует иметь представление о том, как долго он
1 www.postgresql.org/docs/current/view-pg-stats.html
2 www.postgresql.org/docs/current/catalog-pg-statistic.html
3 www.postgresql.org/docs/current/sql-analyze.html
4 www.postgresql.org/docs/current/runtime-config-query.html#GUC-DEFAULT-STATISTICS-TARGET 5 www.postgresql.org/docs/current/sql-explain.html
6 www.postgresql.org/docs/current/pgupgrade.html
9.1. Представление pg_stat_progress_analyze |
223 |
будет продолжаться. Для отслеживания операций сбора статистики используется представление pg_stat_progress_analyze. Каждая строка в представлении соответствует отдельному процессу,собирающему статистику,и содержит следующие поля:
•pid—идентификатор процесса в операционной системе;
•datid,datname—идентификатор и имя базы данных,к которой выполнено подключение;
•relid—идентификатор таблицы,в которой выполняется сбор статистики;
•phase—фаза сбора статистики:
—initializing—подготовка к сканированию таблицы;
—acquiring sample rows—получение случайной выборки строк для анализа;
—acquiring inherited sample rows—получение выборки строк из дочерних таблиц;
—computing statistics—вычисление статистики на основе выбранного набора строк;
—computing extended statistics—вычисление расширенной статистики;
—finalizing analyze—завершение работы,обновление pg_class;
•sample_blks_total—общее количество блоков в случайной выборке,необходимойдля вычисления статистики;
•sample_blks_scanned—общее количество уже просканированных блоков;
•ext_stats_total—количество объектов расширенной статистики;
•ext_stats_computed—количество вычисленных объектов расширенной статистики,увели-
чивается только в фазе computing extended statistics;
•child_tables_total—общее количестводочернихтаблиц,в случае сбора статистики в секционированных таблицах;
•child_tables_done — количество просканированных дочерних таблиц, увеличивается только в фазе acquiring inherited sample rows;
•current_child_table_relid — идентификатор дочерней таблицы, сканируемой в данный момент; содержит актуальное значение только в фазе acquiring inherited sample rows.
Исходные данные из представления могут быть не очень понятны, поэтому для большей информативностиимеетсмыслпровестинекоторуюобработку:транслироватьидентификаторы в имена, перевести блоки в байты и взять дополнительную информацию из pg_stat_activity, соединив представления по полю pid.
Втестовом окружении довольно сложно поймать автоматически сбор статистики,поэтому запрос можно выполнить с помощью \watch 1 и в соседнем сеансе запустить команду ANALYZE.
Впервом сеансе появится подобный вывод:
224 |
Глава 9. Ход выполнения операций |
||
|
# SELECT |
|
|
|
a.pid, now() - a.xact_start AS xact_age, |
||
|
p.datname, p.relid::regclass AS relation, |
||
|
a.state, a.wait_event_type ||'.'|| a.wait_event AS wait_event, |
||
|
p.phase, |
|
|
|
pg_size_pretty(p.sample_blks_total * ( |
||
|
SELECT current_setting('block_size')::int )) AS sample_size, |
||
|
round(100 * p.sample_blks_scanned / |
||
|
greatest(p.sample_blks_total,1), 2) AS "scanned,%", |
||
|
p.ext_stats_total ||'/'|| p.ext_stats_computed AS "ext_total/done", |
||
|
p.child_tables_total ||'/'|| p.child_tables_done AS "child_total/done", |
||
|
current_child_table_relid::regclass AS child_in_progress, |
||
|
a.query |
|
|
|
FROM pg_stat_progress_analyze p |
||
|
INNER JOIN pg_stat_activity a ON p.pid = a.pid |
||
|
ORDER BY now() - a.xact_start DESC; |
||
|
-[ RECORD 1 ]-----+---------------------- |
||
|
pid |
| |
536666 |
|
xact_age |
| |
00:00:07.660563 |
|
datname |
| |
pgbench |
|
relation |
| |
pgbench_accounts |
|
state |
| |
active |
|
wait_event |
| |
IO.DataFileRead |
|
phase |
| |
acquiring sample rows |
|
sample_size |
| |
522 MB |
|
scanned,% |
| |
85.00 |
|
ext_total/done |
| |
0/0 |
|
child_total/done |
| |
0/0 |
|
child_in_progress | |
- |
|
|
query |
| |
ANALYZE; |
Команда ANALYZE выполняется семь секунд, для подсчета статистики нужно получить выборку размером 522 МБ, и на данный момент просканировано уже 85%. В данном примере через пару секунд сканирование будет закончено и начнется фаза подсчета статистики. Для более сложных случаев с секционированнымитаблицами или расширенной статистикой естьдополнительные поля с уточняющей информацией.
9.2. Представление pg_stat_progress_basebackup
Резервное копирование является одной из регулярных задач при эксплуатации производственных СУБД и в зависимости от размеров БД и характеристик оборудования может занимать значительное время. При использовании утилиты pg_basebackup1 выполняется полное копирование файлов данных и необходимых WAL-журналов (для их передачи может запускаться дополнительный процесс walsender). Это создает значительную нагрузку на дисковую
1 www.postgresql.org/docs/current/app-pgbasebackup.html
9.2. Представление pg_stat_progress_basebackup |
225 |
подсистему и может замедлить выполнение конкурентных запросов. В случае нехватки ресурсов и негативного влияния на производительность администратору важно представлять, как долго выполняется и как скоро закончится резервное копирование. Отслеживание встро- еновсамуутилитуpg_basebackup(параметры-P,--progress),носледитьзаходомвыполнения можно и со стороны СУБД с помощью представления pg_stat_progress_basebackup.
Каждая строка представления соответствует отдельному процессу резервного копирования
исодержит следующую информацию:
•pid—идентификатор процесса в операционной системе;
•phase—фаза резервного копирования:
—initializing—подготовка к резервному копированию;
—waiting for checkpoint to finish—walsender ждет завершения контрольной точки;
—estimating backup size—walsender подсчитывает размер файлов БД для передачи;
—streaming database files—walsender передаетданные;
—waiting for wal archiving to finish — walsender ожидает завершения архивирования сегментов WAL-журнала;
—transferring wal files—walsender передаетсегменты WAL-журнала,созданные непосредственно в процессе резервного копирования;
•backup_total — общий объем данных, который будет передан. Значение вычисляется перед резервным копированием и является приблизительной оценкой, поскольку содержимое каталогов данных может измениться в процессе копирования. Если передаваемый объем данных начинает превышать рассчитанное значение, поле устанавливается в backup_streamed. Значение будет отсутствовать (NULL), если расчет оценки
вpg_basebackup отключен (параметр --no-estimate-size);
•backup_streamed — объем переданных данных, увеличивается только в фазах streaming database files и transferring wal files;
•tablespaces_total—общее количество табличных пространств,которые будут переданы;
•tablespaces_streamed — количество уже переданных табличных пространств, увеличива-
ется только в фазе streaming database files.
Чтобыувидетькакие-либорезультаты,стоитвыполнитьприведенныйнижезапросспомощью \watch 1, запустив в соседнем терминале резервное копирование. Поскольку полученная резервная копия нам не понадобится,ее запись можно направить в /dev/null:
# pg_basebackup -P -R -X none -c fast -Ft -h 127.0.0.1 -U postgres -D - > /dev/null
Пока резервное копирование выполняется,в сеансе с запросом к pg_stat_progress_basebackup будет выводиться ход его выполнения: