JavaRush /Курсы /SQL SELF /Системные метрики PostgreSQL

Системные метрики PostgreSQL

SQL SELF
46 уровень , 0 лекция
Открыта

Представьте, что ваш сервер PostgreSQL — это ресторан, а мы — ревизоры. Чтобы ресторан работал стабильно, мы должны учитывать, сколько ингредиентов (CPU, память, диск) используется, как часто они заканчиваются, и кто это всё потребляет. Если мы упустим этот момент, наш "ресторан" может либо принять слишком много заказов и не справиться, либо просто рухнуть прямо посреди дня. Именно поэтому понимание системных метрик жизненно важно.

Ключевые метрики для мониторинга PostgreSQL:

  1. CPU: указывает, сколько процессорного времени тратится на выполнение запросов.
  2. Память (RAM): показывает, как PostgreSQL использует оперативную память, включая кэширование запросов.
  3. Дисковое пространство: пожалуй, самое предсказуемое: вы не можете сохранить больше данных, чем позволяет диск.

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

Мониторинг использования CPU

Процессор — сердце вашего сервера. PostgreSQL может потреблять процессор как для выполнения сложных запросов, так и для фоновых задач, таких как автоанализ и автоочистка базы (autovacuum). Если ваша база данных похожа на ненасытного едока, который жадно "ест" CPU, настало время вмешаться.

  1. Использование системных инструментов.
    Для начала определите, сколько процессорного времени PostgreSQL потребляет на уровне системы. На Linux вы можете использовать команды top или htop.

Найдите процесс PostgreSQL (обычно он содержит имя вашей базы данных). Например, postgres: postgres [your_query].

Обратите внимание на колонку %CPU. Если она постоянно "зашкаливает", это тревожный сигнал.

  1. Анализ нагрузки на CPU из PostgreSQL.

PostgreSQL предоставляет встроенные представления для мониторинга нагрузки. Самое полезное здесь — pg_stat_activity, которое показывает активные запросы.

Пример запроса:

SELECT pid, usename, query, state, now() - query_start AS duration
FROM pg_stat_activity
WHERE state = 'active'
ORDER BY duration DESC;

Что здесь важно?

  • state = 'active' покажет только те запросы, которые в данный момент выполняются.
  • duration покажет, сколько времени запросы уже загружают CPU.

Практический совет:

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

Пример завершения:

SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE state = 'active' AND duration > interval '10 minutes';

Мониторинг использования памяти

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

  1. Основные параметры PostgreSQL для использования памяти:
  • shared_buffers: Это основной блок памяти, выделяемый для работы PostgreSQL. Обычно он занимает 25-40% всей оперативной памяти сервера.
  • work_mem: Память для выполнения операций сортировки и хеширования в одном запросе. Чем больше значение, тем больше временных операций можно выполнять в памяти (а не на диске).
  1. Проверка текущих настроек памяти.

Чтобы увидеть, какие настройки памяти активны для PostgreSQL, выполните команду:

SHOW shared_buffers;
SHOW work_mem;

Пример вывода:

1GB
4MB

Это означает, что на сервер выделено 1 ГБ памяти для shared_buffers и по 4 МБ для каждой операции сортировки/хеширования.

  1. Мониторинг памяти с pg_stat_activity

Вы можете проверить, сколько памяти используется текущими соединениями. Для этого есть удобный запрос:

SELECT pid, usename, state, backend_start, pg_size_pretty(pg_backend_memory_contexts_size(pid)) AS memory_used
FROM pg_stat_activity
WHERE state = 'active'
ORDER BY memory_used DESC;

Этот запрос покажет, сколько оперативной памяти используется каждым активным соединением.

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

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

Диск — это финальный резервуар ресурсов для PostgreSQL. Даже если у вас достаточно памяти и процессорных ресурсов, PostgreSQL нуждается в дисковом пространстве для хранения данных, журналов транзакций (WAL) и временных файлов.

  1. Проверка размера базы данных.

Начнем с базового: определение размера базы данных.

SELECT pg_size_pretty(pg_database_size(current_database())) AS db_size;

Что делает этот запрос?

Он показывает общий размер текущей базы в удобном формате (MB, GB).

  1. Проверка размера таблиц и индексов.

Чтобы определить "тяжеловесов" в базе данных, используйте:

SELECT relname AS table_name, pg_size_pretty(pg_total_relation_size(relid)) AS total_size
FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC;

Пример вывода:

table_name total_size
orders 1 GB
customers 500 MB
transactions 300 MB
  1. Мониторинг WAL (журналов транзакций).

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

SELECT pg_size_pretty(pg_xlog_location_diff(pg_current_wal_lsn(), '0/0')) AS wal_size;

Выводы

Теперь у вас есть инструменты и знания, чтобы следить за системными метриками PostgreSQL:

  1. Используйте htop или pg_stat_activity для мониторинга нагрузки на CPU.
  2. Настройте параметры shared_buffers и work_mem для оптимального использования памяти.
  3. Регулярно проверяйте размер базы данных, таблиц и индексов, чтобы избежать нехватки дискового пространства.

Эти навыки пригодятся вам, чтобы избежать неожиданных сбоев и поддерживать сервер PostgreSQL в отличной форме. Думая о сервере, помните: правильно организованные ресурсы сделают ваш продукт самым популярным среди клиентов (пользователей).

2
Задача
SQL SELF, 46 уровень, 0 лекция
Недоступна
Определение самых больших таблиц в базе данных
Определение самых больших таблиц в базе данных
Комментарии (2)
ЧТОБЫ ПОСМОТРЕТЬ ВСЕ КОММЕНТАРИИ ИЛИ ОСТАВИТЬ КОММЕНТАРИЙ,
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ
Ra Уровень 35 Student
14 августа 2025
Функции pg_xlog_location_diff, pg_backend_memory_contexts_size не находит, видимо в P.16 надо отдельно ставить?
Евгений Уровень 49 Expert
4 ноября 2025
Да нет, кажется, что просто лекция кривая. pg_backend_memory_contexts_size - я такой функции вообще в интернете не нашёл, но существует таблица pg_backend_memory_contexts.