Skip to content
EN

Тюнинг производительности PostgreSQL

Коротко:

Первые 4 рычага: shared_buffers = 25% RAM, effective_cache_size = 75% RAM, work_mem = RAM / (max_connections × 3), maintenance_work_mem = 1-2 GB. Затем включите pg_stat_statements, найдите top-10 по total_exec_time, добавьте индексы через EXPLAIN ANALYZE. Следите за autovacuum (pg_stat_user_tables.last_autovacuum): если вечно отстаёт — увеличьте autovacuum_max_workers.

Ниже: подробности, пример, смежные термины, FAQ.

Проверить свой сайт →

Детали

  • shared_buffers по умолчанию 128 MB — ставьте 25% RAM (4 GB RAM → 1 GB)
  • work_mem влияет на JOIN/ORDER — too low = disk sort, too high = OOM
  • pg_stat_statements: CREATE EXTENSION + 20 MB RAM, stats за все запросы
  • pgbouncer перед Postgres: transaction pool, 10k клиентов → 100 connections
  • EXPLAIN (ANALYZE, BUFFERS) показывает реальный план + disk reads

Пример

-- pgbench benchmark до/после настройки
$ pgbench -c 10 -T 60 mydb

-- top-10 медленных запросов
SELECT query, calls, total_exec_time, mean_exec_time
FROM pg_stat_statements
ORDER BY total_exec_time DESC LIMIT 10;

-- Индекс + verify
CREATE INDEX CONCURRENTLY ON orders (user_id, created_at DESC);
EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM orders WHERE user_id = 1 LIMIT 20;

Связанные

Как настроить производительность PostgreSQL

Чтобы оптимизировать производительность PostgreSQL, необходимо правильно настроить параметры конфигурации, такие как shared_buffers, work_mem и maintenance_work_mem. Рекомендуется установить shared_buffers на 25% от объема оперативной памяти сервера, а work_mem — на 1-2 МБ на соединение. Эти настройки помогут улучшить скорость обработки запросов и общую эффективность работы базы данных.

Ключевые параметры настройки

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

  • shared_buffers: Этот параметр определяет объем памяти, выделяемый для кэширования данных. Рекомендуется устанавливать его на 25% от общей оперативной памяти сервера. Например, для сервера с 16 ГБ ОЗУ это будет 4 ГБ.
  • work_mem: Этот параметр отвечает за объем памяти, выделяемый для операций сортировки и хэширования. Рекомендуется устанавливать его на 1-2 МБ на каждое соединение. Для систем с высокой нагрузкой можно увеличить до 4-8 МБ, но следует учитывать общее количество соединений.
  • maintenance_work_mem: Этот параметр используется для операций обслуживания, таких как VACUUM и CREATE INDEX. Рекомендуется устанавливать его на 10-20% от shared_buffers.
  • effective_cache_size: Этот параметр помогает PostgreSQL оценить, сколько памяти доступно для кэширования данных. Рекомендуется устанавливать его на 50-75% от общей оперативной памяти.

Настройка этих параметров может существенно повлиять на производительность вашего PostgreSQL-сервера.

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

Рассмотрим практический пример конфигурации PostgreSQL для сервера с 32 ГБ оперативной памяти. Для этого откройте файл конфигурации postgresql.conf и внесите следующие изменения:

# Настройка кэширования
shared_buffers = 8GB
work_mem = 4MB
maintenance_work_mem = 2GB
effective_cache_size = 24GB

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

sudo systemctl restart postgresql

Также рекомендуется проводить регулярный мониторинг производительности базы данных. Для этого можно использовать инструменты, такие как enterno.io, которые помогут отслеживать ключевые метрики и выявлять узкие места в производительности.

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

Оценка 0–100Единый балл здоровья сайта
SSL + SecurityБезопасность и сертификат
ПроизводительностьСкорость ответа и кеширование
SEO-сигналыrobots.txt, sitemap, каноникалы

Почему нам доверяют

100
балльная шкала
SSL
SSL + HTTP заголовки
10+
критериев оценки
Free
без регистрации

Как это работает

1

Введите URL сайта

2

Анализируем 10+ факторов

3

Получите общий балл

Что такое Health Score?

Health Score — комплексная оценка технического состояния сайта по 20+ параметрам: SSL, заголовки безопасности, скорость ответа, SEO-технические факторы и доступность.

Комплексная оценка

20+ параметров в одном числе: SSL, заголовки, скорость, SEO-технические факторы.

Детальный разбор

Каждый параметр с объяснением — что проверяется, что найдено, как исправить.

Динамика изменений

Сравнивайте Health Score в разные даты — видите прогресс или регресс.

Мониторинг здоровья

Настройте автоматическую проверку Health Score и получайте уведомление при падении балла.

Кому это нужно

Разработчики

быстрый аудит перед релизом

SEO-специалисты

оценка технической базы

Маркетологи

проверка сайта клиента

Безопасники

экспресс-аудит заголовков

Частые ошибки

Игнорировать красные параметрыКрасный параметр — критичная проблема. Начинайте исправление с них, не с жёлтых.
Проверять только главнуюПроблема может быть на подстраницах. Проверяйте ключевые разделы и посадочные страницы.
Не перепроверять после правокПосле каждого исправления перезапустите проверку и убедитесь, что балл вырос.
Считать 80+ баллов достаточнымСтремитесь к 95+. Каждый красный пункт — это риск для SEO или безопасности.

Лучшие практики

Исправляйте по приоритетамКрасные > жёлтые > синие. Критичные проблемы сначала.
Проверяйте регулярноЕженедельная проверка Health Score помогает заметить деградацию до того, как она влияет на SEO.
Используйте мониторингПодключите автоматический HTTP-монитор — он первым заметит недоступность.
Сравнивайте с конкурентамиПроверьте Health Score ближайшего конкурента — это отличный ориентир для приоритизации.

Получите больше с бесплатным аккаунтом

История Health Score проверок и мониторинг состояния сайта в реальном времени.

Зарегистрироваться (FREE)

Больше по теме

Часто задаваемые вопросы

PgTune — можно верить?

Да, как стартовая точка. pgtune.leopard.in.ua генерирует base config. Дальше — подкручиваете под свой workload (OLTP vs OLAP).

Когда нужны partition'ы?

При таблицах > 100 GB или вырезании старых данных. Для < 10 GB — лишняя сложность.

Connection pooler критичен?

При > 200 concurrent — да, Postgres per-connection backend съедает 10 MB RAM + контекст-свитчи.

Запустить инструмент, который описан в этой статье

Бесплатный тариф — 10 мониторов, проверки каждые 5 мин, без карты. Платные тарифы — интервал от 1 минуты и проверки из нескольких регионов.