Уровень 2.0

Предусловие: изучена глава «Физическое хранение данных».

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

Обслуживание СУБД

Обслуживание системы управления базами данных (СУБД) — это комплекс регулярных и плановых мероприятий, направленных на обеспечение ее стабильной, быстрой и безопасной работы. В состав комплекса мероприятий включены:

контроль за дисковым пространством;
управление данными;
контроль статистики планировщика;
мониторинг производительности;
просмотр журнала событий.

Мониторинг дискового пространства

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

Средства операционной системы

В операционной системе есть основные инструменты для мониторинга дискового пространства — метакоманды df и du.

Команда df показывает информацию о файловых системах: их общий размер, сколько места занято и сколько осталось свободным (см. man df). Опция -h задает вывод информации в удобных единицах. В нашем случае в качестве аргумента подается корневой каталог. Если же вызвать команду df без аргументов, будет выведена информация по всем системам.

[postgres@ServerName ~]$ df -h /dev/mapper/ro_{server_name}-root

Filesystem                          Size  Used  Avail  Use%  Mounted on
/dev/mapper/ro_{server_name}-root    27G   14G    12G   54%  /

В выводе команды видны столбцы общего размера каталога (Size), использованного (Used) и свободного (Avail), а также процент использованного пространства по отношению к общему размеру каталога (Use%).

Вторая команда, du, предназначена для более детального анализа занимаемого пространства конкретным каталогом (см. man du). По умолчанию команда рекурсивно выводит дисковое пространство, занимаемое подкаталогами, которые принадлежат указанному в качестве аргумента каталогу. Опция -s вместо этого выдает суммарное дисковое пространство, занимаемое всеми файлами в этом каталоге.

[postgres@ServerName ~]$ du -sh $PGDATA

195M       /pgdata/06/data

В примере выводится размер всех файлов кластера с помощью переменной $PGDATA.

Если в файловой системе используется квотирование дискового пространства, то сведения об израсходованном пространстве и количестве файлов предоставляет команда quota (см. man quota).

Средства СУБД

В PostgreSQL также есть функции, позволяющие определить размеры базы данных, объектов и слоев:

pg_relation_size() определяет размер слоя в байтах;
pg_indexes_size() определяет суммарный размер всех индексов таблицы;
pg_table_size() определяет размер таблицы с учетом TOAST;
pg_total_relation_size() определяет общий размер таблицы, всех ее индексов и TOAST;
pg_database_size() определяет размер, занимаемый базой данных.

Некоторые из них уже были использованы в предыдущей главе.

к сведению

В СУБД Pangolin доступна функция pgstattuple, которая позволяет собирать статистику на уровне кортежей: информация о точном размере отношений, количестве мертвых версий строк, свободном пространстве для вставки данных и так далее.

Управление данными

Если не проводить регулярную чистку данных, дисковое пространство будет засорено. Это происходит из-за механизма MVCC. В результате работы команды UPDATE строки обновляются: старые версии помечаются как удаленные, а рядом появляются новые версии. И при каждом запуске команды количество обработанных ею версий строк удваивается. Команда DELETE просто помечает удаленные строки с помощью xmax. Удаленные версии строк, не входящие ни в один снимок данных, просто занимают место на диске и ни для чего не нужны. Очистка предотвращает исчерпание дискового пространства в результате раздувания таблиц и индексов.

Очистку можно произвести как вручную с помощью команды VACUUM, так и автоматически — процесс autovacuum. Для ручной очистки в командной строке ОС используется команда vacuumdb.

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

Автоочистка

Процесс autovacuum стирает устаревшие версии строк и оставляет на их месте на страницах пустое пространство, пригодное для вставки новых версий строк. Также в процессе очистки строятся карты видимости и свободного пространства.

Еще одна важная задача, выполняемая очисткой, — предотвращение зацикливания счетчика транзакций для 32-битных систем.

Для предотвращения переполнения используется механизм заморозки. В процессе очистки autovacuum заменяет старые номера транзакций на специальное значение FrozenTransactionId (FROZEN). Замороженные строки считаются видимыми для всех транзакций, и их XID перестает участвовать в дальнейшем исчислении счетчика. Таким образом, автоочистка не только освобождает место на страницах, но и гарантирует безопасную работу счетчика транзакций.

Очистка не блокирует операции чтения и записи, но операции, требующие блокировки таблицы, например CREATE INDEX, будут дожидаться освобождения блокировки.

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

postgres@postgres=# SELECT pid, backend_type FROM pg_stat_activity;

  pid | backend_type
------+------------------------------
| autovacuum launcher
| autounite launcher
| integrity check launcher
| logical replication launcher
| client backend
| background writer
| client backend
| background writer
| checkpointer
| walwriter
(8 rows)

В примере выведены все активные процессы и их pid. Именно autovacuum представлен двумя разновидностями процессов:

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

Параметры автоочистки

По умолчанию механизм autovacuum активен и функционирует в автоматическом режиме. Несмотря на техническую возможность его отключения, делать это не следует.

Для работы подсистемы автоочистки требуется два параметра:

autovacuum — включение автоматической очистки (по умолчанию включен);
track_counts — данный параметр контролирует, собирается ли совокупная статистика о доступе к таблицам и индексам.

Последний параметр необходим, так как autovacuum проверяет собранную статистику по количеству изменений в базах данных для запуска процесса автоочистки.

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

postgres@postgres=# \dconfig autovacuum|track_counts

List of configuration parameters
  Parameter   | Value
--------------+----------
 autovacuum   | on
 track_counts | on
(2 rows)

Как видно, оба параметра включены.

Кроме описанных выше параметров есть еще несколько, обеспечивающих корректную работу подсистемы автоочистки.

Автоочистка запускается для конкретной базы данных при достижении порога, определяемого формулой:

количество_измененных_строк = autovacuum_vacuum_threshold + autovacuum_vacuum_scale_factor * количество_строк_в_таблице.

В этой формуле параметр autovacuum_vacuum_threshold отвечает за пороговое значение количества измененных строк, ниже которого очистка не запустится, а autovacuum_vacuum_scale_factor — за пороговый процент измененных строк, требуемый для срабатывания очистки. То есть параметры autovacuum_vacuum_threshold и autovacuum_vacuum_scale_factor минимальные для запуска процесса автоочистки.

При необходимости данный процесс можно отключить для уже существующей или при создании новой таблицы с помощью параметра autovacuum_enabled. Для TOAST таблиц есть отдельный параметр — toast.autovacuum_enabled.

Важно

Даже при отключенной автоочистке для таблицы (autovacuum_enabled = off) данный процесс все равно запустится для предотвращения переполнения счетчика транзакций (wraparound protection).

Периодичность попыток запуска очистки определяется параметром autovacuum_naptime.

Запущенный процесс очистки работает с паузами для снижения общей нагрузки на систему. Суммарные затраты на действия по очистке, по достижении которых необходимо временно приостановить очистку, прописаны в параметрах vacuum_cost_limit для VACUUM и autovacuum_vacuum_cost_limit для автоочистки. Длительность паузы указана в параметрах vacuum_cost_delay для VACUUM и autovacuum_vacuum_cost_delay для автоочистки.

Максимальное количество запущенных одновременно процессов определено параметром autovacuum_max_workers.

Освобождение места в файловой системе

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

Более глубокую очистку выполняет команда VACUUM FULL. Она полностью блокирует таблицу и последовательно копирует актуальные версии строк в новые файлы данных. После завершения этого процесса меняется oid файлового узла, а старые файлы данных удаляются. В процессе работы VACUUM FULL на диске требуется свободное место не меньшее, чем исходный размер перестраиваемой таблицы.

Команда CLUSTER выполняет похожую работу, но дополнительно еще и упорядочивает строки по ключу при перестроении таблицы.

Перестраиваются индексы командой REINDEX. Есть и менее блокирующий аналог REINDEX CONCURRENTLY.

к сведению

Конкретно в СУБД Pangolin {pangolin_version} поставляется расширение pg_repack, позволяющее в менее блокирующем режиме, чем VACUUM FULL, выполнить перестройку таблицы с уплотнением.

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

На производительность базы данных сильно влияют планы выполняемых запросов. При выполнении запроса с неоптимальным планом время на его выполнение может быть на порядки хуже, чем при использовании оптимального плана.

Планировщику (оптимизатору запросов) необходимы статистические сведения о данных в объектах базы для выработки правильного плана запроса. Так как данные в отношениях базы изменяются, причем нередко весьма значительно, задача сбора статистики — одна из важнейших регулярных задач. Как и очистку, эту задачу в ранних версиях PostgreSQL доверяли системам календарного выполнения задач типа cron. Однако гораздо эффективнее эту задачу решать с помощью автоочистки. Процесс очистки последовательно просматривает страницы отношений для поиска мертвых версий строк. Разумно вместе с этим сразу заботиться и о сборе статистических сведений.

Процесс autovacuum обновляет статистику для конкретной базы данных при достижении порога, определяемого формулой:

количество_измененных_строк = autovacuum_analyze_threshold + autovacuum_analyze_scale_factor * количество_строк_в_таблице.

Параметры аналогичны тем, что используются при запуске автоочистки:

autovacuum_analyze_scale_factor — пороговый процент измененных строк;
autovacuum_analyze_threshold — базовое пороговое значение количества измененных строк.

Эти параметры проверяются в списке конфигурационных параметров. Для удобства используется шаблон по началу имени.

postgres@postgres=# \dconfig autovacuum_analyze*

          List of configuration parameters
            Parameter            |  Value
---------------------------------+----------
autovacuum_analyze_scale_factor  | 0.1
autovacuum_analyze_threshold     | 50
(2 rows)

Для ручного сбора статистики используются команда ANALYZE и команда VACUUM ANALYZE. При работе в командной строке ОС — vacuumdb --analyze и vacuumdb --analyze-only.

Мониторинг производительности

В PostgreSQL 15 была значительно изменена система сбора статистики о работе (не путать со статистикой планировщика). Раньше имелся специальный процесс stats collector. Теперь же все процессы экземпляра самостоятельно собирают статистические данные о своей работе и запоминают их в своей локальной памяти. Периодически эти данные передаются в общую память.

Статистика является кумулятивной, то есть она накапливает подсчитанные значения:

обращений к таблицам с подсчетом строк;
обращений к индексам с подсчетом указателей на строки;
обращений к таблицам с подсчетом блоков;
обращений к индексам с подсчетом блоков;
строк в каждой таблице;
срабатываний очистки для каждой таблицы;
сбора статистики планировщика для каждой таблицы.

Система кумулятивной статистики собирает информацию о текущей активности сервера и подсчитывает обращения к таблицам и индексам в терминах блоков и строк. Количество строк в таблицах, информация о выполненных очистках и сборе статистики подсчитываются для каждой таблицы. Отдельно включается подсчет обращений к пользовательским функциям, который фиксирует время, затраченное на их выполнение. При корректной остановке собранные сведения о кумулятивной статистике сохраняются в каталоге pg_stat, и они доступны при следующем старте.

Управление сбором статистики

Для настройки сбора статистики есть следующие параметры:

track_activities — включает сбор кумулятивной статистики в процессах экземпляра;
track_counts — включает сбор сведений об обращениях к таблицам и индексам;
track_functions — сбор сведений о пользовательских функциях (выключен по умолчанию);
track_io_timing — отслеживание времени, затрачиваемого на чтение и запись блоков данных (выключен по умолчанию);
track_wal_io_timing — отслеживание времени, затрачиваемого на операции записи в WAL (выключен по умолчанию).

Проверить их состояние можно в списке конфигурационных параметров. Для удобства используется маска по началу имени.

postgres@postgres=# \dconfig+ track_*

                       List of configuration parameters
         Parameter         |  Value  |  Type   |  Context   | Access privileges
---------------------------+---------+---------+------------+-------------------
track_activities           | on      | bool    | superuser  |
track_activity_query_size  | 1kB     | integer | postmaster |
track_commit_timestamp     | off     | bool    | postmaster |
track_counts               | on      | bool    | superuser  |
track_functions            | none    | enum    | superuser  |
track_io_timing            | off     | bool    | superuser  |
track_wal_io_timing        | off     | bool    | superuser  |
(7 rows)

Параметр track_activity_query_size не показан, так как он отвечает просто за размер памяти, зарезервированной для хранения кода исполняемых сейчас команд для каждой сессии, выводимых в столбце pg_stat_activity.query.

Представления статистики

PostgreSQL предоставляет два вида представлений для просмотра собранных статистических данных. Динамические представления отражают текущую активность сервера — запущенные процессы, выполняемые запросы, прогресс операций. Представления кумулятивной статистики накапливают сведения за все время работы сервера (или с момента последней корректной остановки) — обращения к таблицам и индексам, срабатывания очистки, ввод-вывод.

Динамические представления

Динамические представления статистики информируют о происходящих в системе процессах в текущий момент времени.

Некоторые из представлений:

pg_stat_activity для каждого процесса экземпляра содержит одну строку со сведениями о текущей работе процесса, его состоянии и обрабатываемом запросе;
pg_stat_replication содержит по одной строке для каждого процесса-отправителя WAL, показывающей статистику репликации на подключенный резервный сервер этого отправителя;
pg_stat_wal_receiver содержит одну строку, показывающую статистику о приемнике WAL с подключенного к нему сервера;
pg_stat_ssl содержит по одной строке для каждого серверного процесса или процесса-отправителя WAL, показывая статистику использования SSL в этом соединении;
pg_stat_gssapi содержит по одной строке для каждого серверного компонента, показывающей информацию об использовании GSSAPI в этом соединении;
pg_stat_progress_analyze содержит строку для каждого серверного процесса, который в данный момент выполняет команду ANALYZE;
pg_stat_progress_create_index содержит по одной строке для каждого серверного процесса, который в данный момент выполняет CREATE INDEX или REINDEX;
pg_stat_progress_vacuum содержит по одной строке для каждого серверного процесса, включая рабочие процессы автоочистки, который в данный момент выполняет VACUUM;
pg_stat_progress_cluster содержит строку для каждого серверного процесса, который в данный момент выполняет CLUSTER или VACUUM FULL;
pg_stat_progress_basebackup содержит строку для каждого процесса-отправителя WAL, который в данный момент выполняет команду репликации BASE_BACKUP и передает резервную копию в потоковом режиме;
pg_stat_progress_copy содержит строку для каждого серверного процесса, который в данный момент выполняет команду COPY.

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

Суперпользователи и роли, обладающие привилегиями встроенной роли pg_read_all_stats, могут видеть всю информацию обо всех сеансах.

Кумулятивная статистика

Представления кумулятивной статистики накапливают подсчитанные значения за все время работы сервера (или с момента последней корректной остановки):

pg_stat_database — статистика на уровне БД;
pg_stat_bgwriter — статистика фоновой записи и контрольных точек;
pg_stat_all_tables — статистика обращений к таблицам;
pg_stat_all_indexes — статистика обращений к индексам;
pg_stat_io — статистика ввода-вывода;
pg_statio_all_tables — статистика обращений к таблицам в блоках;
pg_statio_all_indexes — статистика обращений к индексам в блоках.

Полный список представлений для отображения кумулятивной статистики.

Представления pg_statio_* и pg_stat_io используются для определения эффективности работы буферного кеша. Начиная с версии СУБД Pangolin 6.2.0 поставляются также и расширения для сбора статистики.

postgres@postgres=# SELECT name FROM pg_available_extensions WHERE name ~ 'stat';

        name
--------------------
 pg_dbms_stats
 pg_stat_statements
 pg_query_state
 pgstattuple
 pg_stat_kcache
(5 rows)

Активность транзакций

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

В транзакции доступна ее собственная статистика:

pg_stat_xact_all_tables — обращения ко всем таблицам;
pg_stat_xact_sys_tables — обращения только к системным таблицам;
pg_stat_xact_user_tables — обращение к пользовательским таблицам;
pg_stat_xact_user_functions — обращение к пользовательским функциям.

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

Начнем транзакцию и посмотрим, какая статистика доступна внутри нее.

postgres@sch_db=# BEGIN;

BEGIN

Выведем доступные представления с помощью метакоманды \dv и шаблона по началу имени.

postgres@sch_db*# \dv pg_stat_xact_*

                     List of relations
   Schema   |            Name             | Type |  Owner
------------+-----------------------------+------+----------
 pg_catalog | pg_stat_xact_all_tables     | view | postgres
 pg_catalog | pg_stat_xact_sys_tables     | view | postgres
 pg_catalog | pg_stat_xact_user_functions | view | postgres
 pg_catalog | pg_stat_xact_user_tables    | view | postgres
(4 rows)

Завершим транзакцию.

postgres@sch_db=*# END;

COMMIT

Заголовки процессов и имя приложения

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

Разберем три ключевых параметра:

cluster_name — параметр, задающий уникальное имя для всего кластера баз данных (по умолчанию не задано);
update_process_title — параметр, управляющий тем, будет ли PostgreSQL изменять заголовок серверного процесса при переходе к выполнению новой SQL команды (по умолчанию включен);
application_name — сессионный параметр, который позволяет явно указать имя приложения, устанавливающего соединение с базой данных (отображаться в pg_stat_activity и может совпадать с именем драйвера).

Параметр cluster_name влияет на формирование заголовков серверных процессов, он задает имя кластера, postmaster и всех его фоновых процессов. В режиме репликации Hot Standby автоматически используется как значение application_name для сервера-реплики при подключении к мастеру.

postgres@postgres=# SHOW cluster_name;

 cluster_name
--------------

(1 row)

Параметр update_process_title включает обновление заголовка процесса при выполнении следующей команды SQL.

postgres@postgres=# SHOW update_process_title;

 update_process_title
----------------------
 on
(1 row)

Для удобного отображения имени процесса в представлении pg_stat_activity задается параметр application_name.

postgres@postgres=# SHOW application_name;

 application_name
------------------
 psql
(1 row)

Журнал отчета

Журнал ошибок (error log) — это основной источник информации о работе сервера PostgreSQL. Он фиксирует запуски, подключения, ошибки выполнения, информацию о производительности и служебные события. Правильная конфигурация логирования критически важна для эксплуатации, безопасности и отладки.

Способ ведения журнала

PostgreSQL обладает возможностью вести отчеты с сообщениями разными способами. Способ хранения сообщений, записываемых в журнал, определяет параметр log_destination:

stderr — стандартный поток вывода ошибок. Это базовый внутренний механизм PostgreSQL, который сам по себе не пишет в файлы, но является обязательным источником для встроенного сборщика логов;
csvlog и jsonlog — сообщения будут записываться в CSV и JSON файлы соответственно, форматы которых описаны в документации;
eventlog — предназначен для передачи сообщений системе сбора журналов в MS Windows;
syslog — передача сообщений по прикладному сетевому протоколу SYSLOG, при этом необходимо указать параметр syslog_facility (канал журналирования, по умолчанию LOCAL0).

Передача сообщений по протоколу SYSLOG подходит для построения централизованных систем сбора сообщений от разных устройств. Часто в PostgreSQL используется свой собственный сборщик сообщений, способный выполнять ротацию журналов без дополнительного ПО. В таком случае log_destination = stderr и logging_collector = on.

Сборщик сообщений

При включенном параметре logging_collector = on поток сообщений из stderr передается специальному процессу — сборщику сообщений. Сборщик сообщений самостоятельно записывает сообщения в файл журнала и может выполнять его ротацию. Каталог расположения журнала задается параметром log_directory. Шаблон для имен журнальных файлов задается параметром log_filename в формате strftime, причем суффикс имени файла (.log, .csv, .json) определяется автоматически на основе log_destination. Явно прописывать его в шаблоне не нужно.

Включим сборщик сообщений. В начале убедимся, что в системе имеются нужные папки и postgres может в них писать.

postgres@postgres=# \! ls -ld /pgerrorlogs/ /pgerrorlogs/06/

drwxr-x--- 3 postgres postgres 4096 Oct  21 16:00 /pgerrorlogs/
drwxr-x--- 2 postgres postgres 4096 Oct  21 16:42 /pgerrorlogs/06/

Папки на месте, и у postgres есть все необходимые права. Включим параметр logging_collector.

postgres@postgres=# ALTER SYSTEM SET logging_collector TO on;

ALTER SYSTEM

Установим папку для хранения файлов с логами.

postgres@postgres=# ALTER SYSTEM SET log_directory = '/pgerrorlogs/06';

ALTER SYSTEM

Включение сборщика сообщений требует перезагрузки сервера.

postgres@postgres=# \q

[student@ServerName ~]$ sudo systemctl restart postgresql

Перезагрузка прошла успешно, войдем в оболочку psql и проверим путь к файлу журнала сообщений с помощью функции pg_current_logfile().

[postgres@ServerName ~]$ psql

postgres@postgres=# SELECT pg_current_logfile();

                pg_current_logfile
--------------------------------------------------
 /pgerrorlogs/06/postgresql-2024-10-21_143500.log
(1 row)

Убедиться, что файл журнала открыт процессом postgres, можно с помощью команды lsof.

postgres@postgres=# \! sudo lsof /pgerrorlogs/06/postgresql-2024-10-121_143500.log

COMMAND  PID       USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
postgres 14732 postgres   7w    REG  253,0     1533 1048581 /pgerrorlogs/06/postgresql-2024-10-21_143500.log

Как видно по третьему столбцу, процесс открыт пользователем postgres.

Ротация файлов журналов отчета

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

Для настройки ротации используются следующие параметры:

log_filename — шаблон strftime имени файла, соответствующий периодичности ротации;
log_file_mode — параметр в числовом значении, устанавливающий права на новый файл журнала отчета;
log_rotation_age — время жизни файла журнала отчета до наступления его ротации (по умолчанию 24 часа);
log_rotation_size — размер файла журнала отчета, по достижении которого будет выполнена его ротация (по умолчанию 10 МБ);
log_truncate_on_rotation — параметр, включающий перезапись содержимого файла вместо создания нового.

Некоторые настройки сообщений

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

Когда генерировать сообщения в журнал:

log_min_messages — порог отбрасывания сообщений недостаточной важности;
log_min_duration_statement — параметр определяет порог времени, при превышении которого работающей командой, будет записано сообщение;
log_startup_progress_interval — параметр определяет порог времени выполнения запроса, при превышении которого нужно сообщать о задержке процесса startup.

О чем сообщать:

log_checkpoints — контрольная точка;
log_connections/log_disconnections — подключения/отключения;
log_duration — включать в сообщение длительность команды;
log_error_verbosity — уровень подробностей сообщения;
log_line_prefix — префикс строк сообщений;
log_hostname — включать имя хоста сервера;
log_lock_waits — сообщать о превышении deadlock_timeout при ожидании;
log_statement — о каких командах писать сообщения (off, ddl, mod, all);
log_temp_files — информировать об использовании временных файлов.

Итоги

Мониторинг дискового пространства выполняется средствами ОС (df, du, quota) и функциями СУБД (pg_relation_size(), pg_table_size(), pg_total_relation_size(), pg_database_size());
Механизм MVCC приводит к накоплению мертвых версий строк — своевременная очистка предотвращает распухание таблиц и индексов;
Автоочистка (autovacuum) должна быть включена всегда: она удаляет мертвые строки, строит карты видимости и свободного пространства, а также предотвращает переполнение счетчика транзакций;
Порог запуска автоочистки определяется параметрами autovacuum_vacuum_threshold и autovacuum_vacuum_scale_factor;
VACUUM FULL и CLUSTER перестраивают таблицу, копируя актуальные строки в новые файлы; REINDEX перестраивает индексы;
Сбор статистики планировщика выполняется автоматически процессом autovacuum по порогу, определяемому параметрами autovacuum_analyze_threshold и autovacuum_analyze_scale_factor;
Кумулятивная статистика накапливает данные за все время работы сервера; динамические представления (pg_stat_activity, pg_stat_progress_vacuum, pg_stat_progress_create_index и другие) отражают текущую активность процессов;
Параметры track_activities и track_counts включают базовый сбор статистики; track_functions и track_io_timing включаются дополнительно;
Журнал отчета настраивается через log_destination (stderr/csvlog/jsonlog/syslog) и включение сборщика сообщений (logging_collector);
Ротация файлов журнала управляется параметрами log_rotation_age, log_rotation_size и шаблоном log_filename.

Уровень 2.0

Обслуживание СУБД

Мониторинг дискового пространства

Средства операционной системы

Средства СУБД

Управление данными

Автоочистка

Параметры автоочистки

Освобождение места в файловой системе

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

Мониторинг производительности

Управление сбором статистики

Представления статистики

Динамические представления

Кумулятивная статистика

Активность транзакций

Заголовки процессов и имя приложения

Журнал отчета

Способ ведения журнала

Сборщик сообщений

Ротация файлов журналов отчета

Некоторые настройки сообщений

Итоги

Самопроверка

Вопрос 1

Вопрос 2

Вопрос 3

Вопрос 4

Вопрос 5

Вопрос 6

Вопрос 7

Вопрос 8

Вопрос 9

Вопрос 10

Вопрос 11

Вопрос 12

Обслуживание СУБД​

Мониторинг дискового пространства​

Средства операционной системы​

Средства СУБД​

Управление данными​

Автоочистка​

Параметры автоочистки​

Освобождение места в файловой системе​

Статистика планировщика​

Мониторинг производительности​

Управление сбором статистики​

Представления статистики​

Динамические представления​

Кумулятивная статистика​

Активность транзакций​

Заголовки процессов и имя приложения​

Журнал отчета​

Способ ведения журнала​

Сборщик сообщений​

Ротация файлов журналов отчета​

Некоторые настройки сообщений​

Итоги​

Самопроверка​

Вопрос 1

Вопрос 2

Вопрос 3

Вопрос 4

Вопрос 5

Вопрос 6

Вопрос 7

Вопрос 8

Вопрос 9

Вопрос 10

Вопрос 11

Вопрос 12

Обслуживание СУБД

Мониторинг дискового пространства

Средства операционной системы

Средства СУБД

Управление данными

Автоочистка

Параметры автоочистки

Освобождение места в файловой системе

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

Мониторинг производительности

Управление сбором статистики

Представления статистики

Динамические представления

Кумулятивная статистика

Активность транзакций

Заголовки процессов и имя приложения

Журнал отчета

Способ ведения журнала

Сборщик сообщений

Ротация файлов журналов отчета

Некоторые настройки сообщений

Итоги

Самопроверка