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

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

Основные инструменты

-- Активные запросы
SELECT pid, usename, application_name, query, state 
FROM pg_stat_activity 
WHERE state = 'active';

-- Долгие запросы (> 5 секунд)
SELECT now() - query_start AS duration, query, state 
FROM pg_stat_activity 
WHERE state = 'active' AND now() - query_start > '5 seconds'::interval;

pg_stat_statements
Включение модуля для анализа запросов:

ALTER SYSTEM SET shared_preload_libraries = 'pg_stat_statements';
CREATE EXTENSION pg_stat_statements;

-- Топ-5 самых ресурсоемких запросов
SELECT query, calls, total_time, rows, 
       100.0 * shared_blks_hit / nullif(shared_blks_hit + shared_blks_read, 0) AS hit_percent
FROM pg_stat_statements 
ORDER BY total_time DESC 
LIMIT 5;

EXPLAIN и EXPLAIN ANALYZE
Разбор плана выполнения запроса:

EXPLAIN ANALYZE
SELECT * FROM orders 
WHERE customer_id = 123 
AND order_date > '2023-01-01';

Эффективное использование индексов

Типы индексов и их применение

Оптимизация индексов

Покрывающие индексы (INCLUDE):

CREATE INDEX orders_customer_date_idx ON orders (customer_id) INCLUDE (order_date, total_amount);

Частичные индексы:

CREATE INDEX active_users_idx ON users (email) WHERE is_active = true;

Анализ использования индексов:

SELECT schemaname, relname, indexrelname, idx_scan,
       100 * idx_scan / (seq_scan + idx_scan) AS idx_usage_percent
FROM pg_stat_user_tables 
WHERE seq_scan + idx_scan > 0;

Оптимизация запросов

Распространенные антипаттерны

1. N+1 запросов:

   • Проблема: Множество отдельных запросов вместо одного

   • Решение: Использовать JOIN и агрегацию

2. Избыточные данные:

-- Неоптимально
SELECT * FROM customers;

-- Оптимально
SELECT id, name, email FROM customers;

3. Неэффективные JOIN:

   • Всегда фильтруйте данные перед соединением таблиц

Оптимизация сложных запросов

CTE vs подзапросы:

-- Часто неоптимально (материализация)
WITH recent_orders AS (
    SELECT * FROM orders WHERE order_date > now() - interval '30 days'
)
SELECT * FROM recent_orders JOIN customers USING (customer_id);

-- Оптимальная альтернатива
SELECT * 
FROM orders o
JOIN customers c USING (customer_id)
WHERE o.order_date > now() - interval '30 days';

Оконные функции вместо кореллированных подзапросов:

-- Неоптимально
SELECT name, 
       (SELECT COUNT(*) FROM orders WHERE customer_id = c.id) AS order_count
FROM customers c;

-- Оптимально
SELECT name, COUNT(o.id) OVER (PARTITION BY customer_id) AS order_count
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id;

Конфигурация сервера

Ключевые параметры памяти

# postgresql.conf

# 25-40% от общей памяти
shared_buffers = 8GB

# Для операций сортировки и соединения
work_mem = 32MB

# Для операций обслуживания (VACUUM, CREATE INDEX)
maintenance_work_mem = 2GB

# Размер кэша ОС для данных
effective_cache_size = 24GB

Правильная настройка параметров памяти критически важна для производительности PostgreSQL. Рассмотрим ключевые параметры с формулами расчета и практическими рекомендациями.

shared_buffers (общий буферный кэш)

Назначение: Основной кэш для данных и индексов

Рекомендации:

# Формула для систем с > 4GB RAM:
shared_buffers = min(25% RAM, 8GB) для OLTP
shared_buffers = min(40% RAM, 32GB) для OLAP

# Примеры:
RAM 16GB → 4GB (16 * 0.25)
RAM 64GB → 8GB (предел для OLTP)
RAM 256GB → 32GB (для OLAP)

Особенности:

• Не должен превышать 40% RAM
• Для Windows: не более 512MB-1GB из-за архитектурных ограничений
• После изменения требуется перезагрузка сервера

work_mem (память для операций)

Назначение: Память для сортировки, хешей, оконных функций
Рекомендации:

# Формула:
work_mem = (RAM - shared_buffers) / (max_connections * параллельные операции)

# Безопасный расчет:
work_mem = (RAM - shared_buffers) / (max_connections * 3)

# Пример для 16GB RAM, 100 подключений:
(16384MB - 4096MB) / (100 * 3) = 12288 / 300 ≈ 40MB

Важно:

• Значение задается на операцию, а не на соединение
• Один запрос может использовать несколько раз work_mem
• Типичный диапазон: 4MB-64MB
• Слишком высокое значение → риск OOM (out of memory)

maintenance_work_mem (память для обслуживания)

Назначение: Операции VACUUM, CREATE INDEX, ALTER TABLE
Рекомендации:

# Формула:
maintenance_work_mem = min(10% RAM, 1GB) для баз < 50GB
maintenance_work_mem = min(5% RAM, 10GB) для крупных БД

# Примеры:
RAM 16GB → 1GB
RAM 128GB → 10GB (макс. эффективное значение)

Особенности:

• Можно временно увеличивать для операций перестроения индексов
• Не влияет на обычные запросы

effective_cache_size (оценочный параметр)

Назначение: Оценка доступного кэша ОС для планировщика
Рекомендации:

# Формула:
effective_cache_size = (RAM - shared_buffers) + файловый кэш ОС

# Практическое правило:
effective_cache_size = 50-75% от общего RAM

# Пример:
RAM 64GB → 40GB

Важно: Это информационный параметр, не выделяет реальную память!

temp_buffers (временные буферы)

Назначение: Буферы для временных таблиц
Рекомендации:

# По умолчанию 8MB обычно достаточно
# Для ETL-процессов:
temp_buffers = 16-256MB

huge_pages (большие страницы памяти)

Назначение: Уменьшение накладных расходов
Рекомендации:

huge_pages = try   # или on для включенных систем

Требования:

• Необходима настройка в Linux: vm.nr_hugepages
• Расчет страниц: nr_hugepages = ceil(shared_buffers / 2MB)

wal_buffers (буфер WAL)

Назначение: Кэш для записей журнала
Рекомендации:

# Автовычисление обычно достаточно
# Ручная настройка:
wal_buffers = max(shared_buffers * 0.03, 16MB)

# Пример для shared_buffers=4GB:
4096MB * 0.03 ≈ 123MB → 128MB

Формулы расчета для разных размеров БД

Для сервера 8GB RAM (небольшая БД)

shared_buffers = 2GB
work_mem = 8MB
maintenance_work_mem = 512MB
effective_cache_size = 6GB
wal_buffers = 16MB

Для сервера 64GB RAM (производственная БД)

shared_buffers = 16GB
work_mem = 32MB
maintenance_work_mem = 8GB
effective_cache_size = 40GB
wal_buffers = 128MB
temp_buffers = 64MB

Для сервера 256GB RAM (аналитическая БД)

shared_buffers = 32GB
work_mem = 128MB
maintenance_work_mem = 32GB
effective_cache_size = 180GB
wal_buffers = 256MB
temp_buffers = 256MB

Практические советы по настройке

Постепенная оптимизация:

# Шаг 1: Настройте shared_buffers
# Шаг 2: Оптимизируйте work_mem на основе EXPLAIN ANALYZE
# Шаг 3: Настройте maintenance_work_mem под размер индексов

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

-- Потребление work_mem
SELECT query, work_mem, max_work_mem 
FROM pg_stat_activity 
WHERE state = 'active';

-- Эффективность кэша
SELECT sum(blks_hit) * 100 / (sum(blks_hit) + sum(blks_read)) AS hit_ratio
FROM pg_stat_database;

Динамическая корректировка:

-- Временное увеличение для тяжелой операции
SET LOCAL work_mem = '256MB';
CREATE INDEX CONCURRENTLY ...;

Автоматизация расчета:
Используйте инструменты:

• PGTune
• PoWA для сбора статистики
• pg_qualstats для анализа предикатов

Распространенные ошибки

1. Слишком высокий work_mem:

-- При 100 подключениях:
work_mem = 256MB → потенциальное использование 25.6GB
-- Риск: OOM killer завершит процессы PostgreSQL

2. Недостаточный maintenance_work_mem:

   • VACUUM и CREATE INDEX будут работать медленно
   • Увеличивает время обслуживания БД

3. Игнорирование effective_cache_size:

   • Планировщик будет недооценивать стоимость сканирования по индексу
   • Результат: выбор полного сканирования таблицы вместо индекса

Параметры планировщика

# Стоимость чтения последовательного блока
seq_page_cost = 1.0

# Стоимость чтения случайного блока (для SSD уменьшить)
random_page_cost = 1.1

# Параллельное выполнение
max_parallel_workers_per_gather = 4
min_parallel_table_scan_size = 8MB

Настройки автовакуума

autovacuum_vacuum_scale_factor = 0.05
autovacuum_analyze_scale_factor = 0.02
autovacuum_vacuum_cost_limit = 2000
autovacuum_naptime = 1min

Расширенные техники оптимизации

Табличное партиционирование

-- Создание партиционированной таблицы
CREATE TABLE orders (
    id SERIAL,
    order_date DATE NOT NULL,
    customer_id INT NOT NULL,
    amount NUMERIC(10,2)
) PARTITION BY RANGE (order_date);

-- Создание партиций
CREATE TABLE orders_2023_q1 PARTITION OF orders
    FOR VALUES FROM ('2023-01-01') TO ('2023-04-01');

CREATE TABLE orders_2023_q2 PARTITION OF orders
    FOR VALUES FROM ('2023-04-01') TO ('2023-07-01');

Репликация и шардирование

Архитектура высокой доступности:

Основной сервер (Primary)
        |
        v
Синхронная реплика (Sync Standby)
        |
        v
Асинхронные реплики (Async Standby) -> Читающие реплики

Шардирование с помощью Citus:

-- Создание распределенной таблицы
SELECT create_distributed_table('orders', 'customer_id');

-- Выполнение запроса на всех шардах
SELECT * FROM orders WHERE customer_id = 12345;

Использование расширений

-- Кэширование сложных запросов
CREATE EXTENSION pg_pooler;

-- Сжатие данных
CREATE EXTENSION pg_compression;

-- Ускорение JOIN
CREATE EXTENSION pg_ivm;

Техники обслуживания БД

Стратегии вакуума

ALTER TABLE orders SET (
    autovacuum_vacuum_scale_factor = 0.01,
    autovacuum_vacuum_cost_delay = 5
);

-- Ручной вакуум для больших таблиц
VACUUM (VERBOSE, ANALYZE) large_table;

Перестройка индексов

-- Одновременная перестройка без блокировки
REINDEX INDEX CONCURRENTLY orders_customer_idx;

-- Перестройка всех индексов таблицы
REINDEX TABLE orders;

Мониторинг состояния БД

-- Проверка "раздувания" таблиц
SELECT schemaname, relname, 
       n_dead_tup, 
       pg_size_pretty(pg_relation_size(relid)) AS size
FROM pg_stat_user_tables
WHERE n_dead_tup > 1000
ORDER BY n_dead_tup DESC;

Заключение

Оптимизация PostgreSQL — комплексный процесс, требующий глубокого понимания как самой СУБД, так и особенностей вашего приложения. Ключевые принципы:

1. Измеряйте перед оптимизацией: Используйте мониторинг для выявления реальных проблем

2. Индексы ≠ панацея: Правильные индексы важны, но их избыток вредит производительности

3. Конфигурация контекстна: Нет универсальных настроек — тестируйте под свою нагрузку

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

5. Автоматизируйте обслуживание: Настройте автовакуум и регулярные проверки

Оптимизация PostgreSQL — это постоянный процесс, а не разовое мероприятие. Регулярный мониторинг, анализ производительности и постепенная настройка позволят поддерживать вашу базу данных в оптимальном состоянии даже при росте нагрузки и объема данных.