Как протестировать PostgreSQL за 1 час: быстрая диагностика производительности и целостности

У вас есть всего час, чтобы оценить здоровье и производительность экземпляра PostgreSQL? Это реально. Такой сжатый аудит не заменит глубокого анализа, но позволит выявить критические проблемы, узкие места и даст понимание, куда двигаться дальше. Этот план действий разбит на четкие 10-15 минутные блоки, фокусируясь на самых важных аспектах: конфигурация, производительность, целостность данных и мониторинг.

Первые 15 минут посвятите общему осмотру и сбору системной информации. Подключитесь к базе данных с правами суперпользователя или мониторинга. Начните с версий: `SELECT version();` покажет детальную информацию о PostgreSQL и операционной системе. Проверьте время работы: `SELECT pg_postmaster_start_time();` — длительный аптайм может быть как хорошим признаком, так и указывать на боязнь перезагрузки из-за проблем. Запросите список баз данных и их размер: `SELECT datname, pg_size_pretty(pg_database_size(datname)) as size FROM pg_database;`. Это даст первое представление о масштабе.

Следующий блок — анализ текущей активности и блокировок. Запустите запрос к представлению `pg_stat_activity`: `SELECT pid, usename, application_name, client_addr, state, query, query_start FROM pg_stat_activity WHERE state != 'idle' ORDER BY query_start;`. Ищите «висячие» запросы (с большим `query_start`), особенно в состоянии `active`. Это прямые кандидаты на проблему производительности. Затем проверьте блокировки: `SELECT blocked_locks.pid AS blocked_pid, blocked_activity.query AS blocked_query, blocking_locks.pid AS blocking_pid, blocking_activity.query AS blocking_query FROM pg_catalog.pg_locks blocked_locks JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid JOIN pg_catalog.pg_locks blocking_locks ON blocking_locks.locktype = blocked_locks.locktype AND blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid AND blocking_locks.pid != blocked_locks.pid JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid WHERE NOT blocked_locks.granted;`. Наличие строк здесь — явный сигнал о конфликтах, тормозящих работу.

Третий этап (15 минут) — оценка производительности и статистики. Изучите настройки конфигурации, критичные для производительности: `SHOW shared_buffers; SHOW work_mem; SHOW maintenance_work_mem; SHOW effective_cache_size;`. Сравните их с рекомендациями для вашего объема RAM и типа нагрузки. Далее проанализируйте статистику по индексам. Ключевой запрос к `pg_stat_user_indexes`: посмотрите на соотношение `idx_scan` (сколько раз индекс использовался) и `idx_tup_read`. Индекс с нулевым или очень низким `idx_scan` — кандидат на удаление, так как он замедляет запись. Проверьте наличие последовательных сканирований больших таблиц в `pg_stat_user_tables` (поле `seq_scan`) при высоком `seq_tup_read`. Это может указывать на недостаток индексов.

Четвертый блок посвящен целостности и обслуживанию. Проверьте актуальность статистики: давно не обновляемая статистика ведет к плохим планам запросов. Можно оценить по `last_analyze` и `last_autoanalyze` в `pg_stat_user_tables`. Запустите команду `VACUUM VERBOSE;` для одной из ключевых таблиц — она не блокирует операции, но покажет объем «мертвых» строк. Большое количество мертвых туплов — признак необходимости более агрессивного автовакуума или ручного вмешательства. Обязательно выполните проверку на вздутие (bloat) индексов и таблиц, используя запросы из расширения `pgstattuple` или скрипты с официального wiki. Вздутие — тихий убийца производительности.

Последние 15 минут — это проверка резервного копирования, репликации и логов. Убедитесь, что механизм резервного копирования (pg_dump, pg_basebackup, Barman) настроен и последние бекапы успешны. Проверьте наличие реплик: `SELECT * FROM pg_stat_replication;`. Если репликация настроена, убедитесь в отсутствии лагов (`pg_stat_replication.replay_lag`). Наконец, загляните в логи PostgreSQL. Быстро просмотрите последние несколько сотен строк лог-файла (обычно в `pg_log/`), ища ключевые слова: ERROR, FATAL, WARNING, а также сообщения о долгих запросах (проверьте параметр `log_min_duration_statement`). Это прямой источник информации о сбоях и медленных операциях.

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