List Issues Suggestions1 Discussions Insights

🧙 Садовник: уточнил шаги, добавил проверки и обоснования. Примите, если полезно.

open+2−6⇅5proposed by devops · Aug 16, 2026 · based on v2

Conversation Checks Proposed changes13 Result

Result · becomes v3

Найти, какой именно запрос медленный

Перед любой правкой надо знать конкретный запрос. Включи лог медленных запросов:

sql

1-- логировать всё, что дольше секунды

2ALTER SYSTEM SET log_min_duration_statement = 1000;

3SELECT pg_reload_conf();

Либо ставь расширение pg_stat_statements и смотри топ по суммарному времени:

sql

1SELECT calls, mean_exec_time, total_exec_time, query

2FROM pg_stat_statements

3ORDER BY total_exec_time DESC

4LIMIT 10;

Колонка total_exec_time важнее, чем mean_exec_time: запрос на 50 мс, выполняемый десять тысяч раз, съедает больше, чем один на четыре секунды.

Why: Оптимизация без измерения — это угадывание. За общим «база медленная» обычно стоит один-два конкретных запроса, а остальное работает нормально.

code

1SELECT calls, mean_exec_time, query FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 10;

–Известен конкретный текст медленного запроса
–Ты смотрел на суммарное время, а не только на среднее

pg_stat_statements — статистика по запросам Чеклист по медленным запросам

Посмотреть план выполнения

sql

1EXPLAIN (ANALYZE, BUFFERS) SELECT ...;

Что искать в выводе:

Строка в плане	Что значит
`Seq Scan` по большой таблице	нет нужного индекса
`rows=1` в плане, `actual rows=50000`	статистика устарела, нужен `ANALYZE`
тот же узел с `loops=200`	классическая проблема N+1
`Sort Method: external merge Disk`	не хватает `work_mem`

Вывод удобно разбирать в визуализаторе — ссылка ниже.

Why: Этого шага в исходном плане не было вообще — и это главная его слабость. Запрос на четыре секунды при небольшом объёме данных почти никогда не лечится памятью. Обычно это отсутствующий индекс или N+1 — и тогда одна строка даёт выигрыш в сотни раз, а не на 20%.

code

1EXPLAIN (ANALYZE, BUFFERS) SELECT ...;

–Ты знаешь, есть ли Seq Scan по большой таблице
–Проверил, не N+1 ли это

Как читать EXPLAIN Визуализатор планов запросов Индексы в PostgreSQL

Настройки PostgreSQL — и главная ловушка

Значения по умолчанию не зависят от объёма памяти машины: shared_buffers всегда 128 МБ, work_mem — 4 МБ. На сервере с 4 ГБ это мало.

Вот как НЕ работает — именно так было написано в исходном плане:

yaml

1environment:

2 POSTGRES_SHARED_BUFFERS: 1GB # такой переменной не существует

3 POSTGRES_WORK_MEM: 16MB # и такой тоже

Официальный образ postgres знает только POSTGRES_PASSWORD, POSTGRES_USER, POSTGRES_DB, POSTGRES_INITDB_ARGS, POSTGRES_HOST_AUTH_METHOD и PGDATA. Всё остальное он просто игнорирует — без единого предупреждения.

Вот как работает:

yaml

1postgres:

2 image: postgres:16-alpine

3 command: >

4 postgres

5 -c shared_buffers=1GB

6 -c effective_cache_size=3GB

7 -c work_mem=16MB

8 -c maintenance_work_mem=256MB

Отправная точка для расчёта: shared_buffers около 25% от памяти, effective_cache_size — 50–75%.

Why: Это самый опасный вид ошибки: правка внесена, контейнер поднялся, ошибок нет — и ничего не изменилось. Задача закрыта, галочка стоит, проблема на месте.

code

1docker exec -it <контейнер> psql -U postgres -c "SHOW shared_buffers;"

–Настройки заданы через command с -c или файлом конфига
–SHOW shared_buffers показывает новое значение, а не 128MB

Какие переменные понимает образ postgres Настройки памяти PostgreSQL

Кэш: поднять время жизни и сразу же продумать сброс

Для редко меняющихся данных время жизни в 10 минут действительно мало:

python

1# было везде 600 секунд

2SEO_TTL = 3600 # час

3ANALYTICS_TTL = 7200 # два часа

4CONTACTS_TTL = 1800 # полчаса

Но вместе с этим обязательно сброс при записи:

python

1async def update_contacts(self, data):

2 result = await self.repo.update(data)

3 await self.cache.delete("site_content:contacts") # без этой строки

4 return result # админ будет

5 # в ярости

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

Проверить, что кэш работает:

bash

1docker exec -it <redis> redis-cli

2> KEYS site_content:*

3> TTL site_content:contacts

Why: Кэш — это размен: скорость в обмен на актуальность. Чем больше время жизни, тем больше платишь. Поднять время жизни без сброса при записи — значит перенести жалобы с медленного сайта на «я всё поменял, а ничего не поменялось».

code

1docker exec -it <redis> redis-cli TTL site_content:contacts

–Время жизни поднято только там, где данные редко меняются
–Каждый метод записи сбрасывает свой ключ
–Проверено вручную: поменял через админку — сразу видно на сайте

Пул подключений — когда он действительно нуженOptional

Каждое подключение к PostgreSQL — это отдельный процесс на сервере базы. Сотня подключений — сотня процессов.

Но сначала проверь, есть ли проблема:

sql

1SELECT count(*), state FROM pg_stat_activity GROUP BY state;

2SHOW max_connections;

Если подключений десяток из ста возможных — пул не нужен, это не узкое место.

Если нужен — есть два уровня:

Пул в самом приложении. У SQLAlchemy он включён по умолчанию — проверь pool_size и max_overflow прежде, чем ставить что-то ещё.
Внешний пул (PgBouncer). Нужен, когда к базе ходят несколько разных приложений или много копий одного.

У PgBouncer есть важное ограничение: в режиме transaction не работают подготовленные выражения и сеансовые настройки. Для asyncpg это значит, что нужно явно отключать кэш выражений, иначе получишь плавающие ошибки под нагрузкой.

Why: Пул — самый дорогой из трёх шагов и самый слабый по эффекту. Ставить его первым — верный способ потратить день и получить новый источник странных ошибок.

code

1SELECT count(*), state FROM pg_stat_activity GROUP BY state;

–Проверено, что подключения действительно заканчиваются
–Сначала посмотрели пул самого приложения

PgBouncer — документация

Проверить актуальные версии инструментов

Убедитесь, что используете актуальные версии PostgreSQL и Redis, чтобы избежать проблем с совместимостью и использовать последние улучшения производительности.

Why: Актуальные версии содержат исправления и улучшения, которые могут значительно повлиять на производительность.

A person is needed here: Какие версии PostgreSQL и Redis у вас?

Проверить настройки конфигурации

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

Why: Неправильные настройки могут привести к неэффективному использованию ресурсов и медленной работе базы данных.

A person is needed here: Вы проверяли настройки конфигурации?