PostgreSQL: настройка под нагрузку

Используйте эту инструкцию, чтобы подобрать ресурсы PostgreSQL, применить параметры и оценить результат на импорте и просмотре архива. Устройство базы описано отдельно: {{ССЫЛКА:reference.database|База данных: устройство и параметры}}.

Перед началом

• Проверьте {{ССЫЛКА:install.sizing|расчёт ресурсов}} и доступный объём памяти сервера или контейнера PostgreSQL.
• Подготовьте {{ССЫЛКА:maintenance.backup-db|резервную копию базы}} и сохраните действующую конфигурацию.
• Подключитесь к нужному экземпляру через psql с правами администратора PostgreSQL.
• Измерьте время типичного импорта и выдачи списка писем до изменений.
• Для параметров, требующих перезапуска, выберите окно обслуживания: все узлы Клавдия используют общую базу.

Определите профиль нагрузки

Сценарий	На что обратить внимание
Всё-в-одном	общий бюджет памяти PostgreSQL, Solr, узла Клавдия и ОС
Массовый импорт	скорость записи, контрольные точки WAL, рост таблиц и работа автоочистки
Много пользователей архива	планы запросов, чтение с диска, сортировки и число одновременных запросов

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

Подберите параметры

Параметр	8–16 ГБ	32 ГБ	64 ГБ и больше	Назначение
shared_buffers	2–4 ГБ	8 ГБ	начать с 16 ГБ	общий кеш данных PostgreSQL
effective_cache_size	50–70% доступной памяти	50–70%	50–70%	оценка доступного кеша для планировщика; включает общий кеш PostgreSQL и файловый кеш ОС, не выделяет память
work_mem	16–32 МБ	32–64 МБ	начать с 64 МБ	базовый лимит памяти операции сортировки или хеширования
maintenance_work_mem	256–512 МБ	1 ГБ	до 2 ГБ	память операций обслуживания, например создания индексов и VACUUM
max_wal_size	2 ГБ	4 ГБ	8 ГБ	ориентир объёма WAL между контрольными точками

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

max_wal_size не является жёстким ограничением каталога WAL. При интенсивной записи или проблемах с архивированием журнал может занимать больше места.

Сохраните исходные значения

В psql выполните:

SELECT name, setting, unit, context, source, sourcefile, pending_restart
FROM pg_settings
WHERE name IN (
    'shared_buffers', 'effective_cache_size', 'work_mem',
    'maintenance_work_mem', 'max_wal_size', 'max_connections'
)
ORDER BY name;

Сохраните вывод. Поле sourcefile помогает определить, откуда приходит действующее значение. Если PostgreSQL запускается с параметрами командной строки или конфигурацией, управляемой внешней системой, изменяйте соответствующий источник.

Примените параметры

Ниже пример для выделенного сервера PostgreSQL с 32 ГБ памяти. Не применяйте его автоматически к установке «всё-в-одном».

ALTER SYSTEM SET shared_buffers = '8GB';
ALTER SYSTEM SET effective_cache_size = '20GB';
ALTER SYSTEM SET work_mem = '32MB';
ALTER SYSTEM SET maintenance_work_mem = '1GB';
ALTER SYSTEM SET max_wal_size = '4GB';
SELECT pg_reload_conf();

Команды ALTER SYSTEM выполняйте отдельно, вне блока транзакции. Они записывают параметры в postgresql.auto.conf.

После перечитывания конфигурации повторите запрос к pg_settings. shared_buffers требует перезапуска; work_mem, effective_cache_size, maintenance_work_mem и max_wal_size — перечитывания конфигурации. Если pending_restart = true, перезапустите именно этот экземпляр PostgreSQL штатным способом вашей установки. Новые значения work_mem проверяйте также в соединениях приложения: отдельные сеансы могут иметь собственные настройки.

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

Дополнительно для массового импорта

Проверьте автоочистку

Массовые удаления по сроку хранения оставляют строки, которые должна обработать автоочистка (autovacuum (!)). Для больших таблиц оцените её работу:

SELECT relname, n_live_tup, n_dead_tup, last_autovacuum, last_autoanalyze
FROM pg_stat_user_tables
WHERE schemaname = 'emails'
  AND relname IN ('messages', 'attachments');

Если очистка запаздывает, для этих таблиц можно снизить долю изменённых строк, при которой она запускается: например, с типового значения 0.2 до 0.02. Настройка:

ALTER TABLE emails.messages
    SET (autovacuum_vacuum_scale_factor = 0.02);
ALTER TABLE emails.attachments
    SET (autovacuum_vacuum_scale_factor = 0.02);

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

Проверьте WAL и соединения

• При частых контрольных точках во время начальной загрузки рассмотрите увеличение max_wal_size, например до 8 ГБ, если есть дисковый запас. После загрузки повторно оцените необходимый размер.
• Рассчитывайте max_connections по сумме лимитов пулов всех узлов, подключений обслуживания и резерву администратора. Оценка «число узлов × 10» не заменяет фактические лимиты.
• Не увеличивайте число соединений при исчерпании пула без диагностики. См. {{ССЫЛКА:maintenance.db-pool|Что делать при исчерпании пула соединений}}.

Текущие соединения можно проверить так:

SELECT datname, state, count(*)
FROM pg_stat_activity
WHERE backend_type = 'client backend'
GROUP BY datname, state
ORDER BY datname, state;

Дополнительно для медленной выдачи архива

Проверьте план конкретного запроса. EXPLAIN (ANALYZE, BUFFERS) действительно выполняет запрос, поэтому используйте его для безопасного запроса чтения в контролируемых условиях. Сортировка на диске может указывать на недостаточный work_mem, но медленный ответ также бывает вызван планом, объёмом чтения или конкуренцией за ресурсы.

Меняйте один параметр за раз и сравнивайте одинаковые операции. При высокой конкуренции за память рассмотрите вынос PostgreSQL и Solr на разные серверы.

Проверьте результат и подготовьте откат

1. Проверьте действующие значения в pg_settings и отсутствие ожидающего перезапуска после обслуживания.
2. На {{ССЫЛКА:maintenance.dashboard|панели состояния}} проверьте доступность базы и пул соединений.
3. Повторите тестовый импорт и выдачу списка писем. Сравните время, память, дисковые задержки и журнал PostgreSQL.
4. Для массового импорта проверьте контрольные точки WAL и свободное место на диске.
5. Если результат ухудшился, верните сохранённые значения в тот же источник конфигурации. Перечитайте конфигурацию или выполните перезапуск для параметров, которым он требуется.

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

ALTER TABLE emails.messages RESET (autovacuum_vacuum_scale_factor);
ALTER TABLE emails.attachments RESET (autovacuum_vacuum_scale_factor);

Связанные материалы

• {{ССЫЛКА:reference.database|База данных: устройство и параметры }}
• {{ССЫЛКА:install.external-postgresql|Подготовка внешнего PostgreSQL PostgreSQL}}
• {{ССЫЛКА:maintenance.db-health|Проверка состояния PostgreSQL PostgreSQL}}
• Документация PostgreSQL: память и ресурсы
• Документация PostgreSQL: планировщик
• Документация PostgreSQL: WAL
• Документация PostgreSQL: применение конфигурации

Навигация по книге

• Следующая статья: {{ССЫЛКА:maintenance.backup-overview|Что необходимо резервировать }}