Добрый день. Пожалуйста подскажите, в какую сторону копать.

Сервер RedHat, 12 процессоров, 32GB память. БД 2ТБ
Реплика такая же. Всякие отчеты и очень крупные запросы на реплике делаются.

Настройки сервера
max_connections = 1000
shared_buffers = 8GB
effective_cache_size = 24GB
maintenance_work_mem = 8192MB
checkpoint_completion_target = 0.7
wal_buffers по умолчанию
default_statistics_target = 100
seq_page_cost = 0.1
random_page_cost = 0.11
work_mem = 2048MB
min_wal_size = по умолчанию
max_wal_size = 64MB
max_worker_processes = 8


Мониторинг в пике показал
number of active connection 105
number of idle connections 310
number of idle in transaction connections 149
number of total connections 509

Не сказать, что цифры космические по пользователям, сервер наглухо завис.
В pg_stat_activity в это время наблюдается 300 запросов,
порядка 200 в состоянии idle
порядка 40 в состоянии idle in transaction
и порядка 50 в состоянии active

Сервер встал намертво. Да в момент входа пользователя в систему выполняется огромный селект, который проворачивает полбазы, но тем не менее он максимально оптимизирован и выполняется 0.5-0.8сек. Одновременно таких селектов в pg_stat_activity наблюдаю с десяток.

По памяти мониторинг показывает в пике израсходовал 6Gb shared buffers, то есть далеко не всю.

Какая то печальная картина для 300-400 пользователей. Планируется 3000 пользователей.

Как раскачать сервер под такие задачи?
Правильно я понимаю, что селекты даже по 0.5сек не должны быть проблемой, ведь еще параллельное выполнение должно быть?

1. То есть правильно я понимаю, при 12 ядрах, одновременно можно рассчитывать на выполнение примерно 12 запросов?
2. Время отклика на любое действие в системе выросло до 6-12сек
3. Утилизация дисков как я понимаю не настроена для отображения.

Maxim Boguk,

Maxim Boguk,

Maxim Boguk,

Maxim Boguk,

Maxim Boguk, ну вот у меня пара частых суровых запроса по 600 строк кода, но оптимизировал до 0.5-0.8сек, в зависимости от распределения данных, дальше для оптимизации путей не вижу. А остальные запросы почти мгновенные.

Да, проверил
[always] madvise never

mefman,max_parallel_workers_per_gather в файле конфигурации вообще нет, очевидно имеет умолчательное значение.

Выкладывать план скорее не имеет смысла, потому что, чтоб его просмотреть, можно скрол на мышке стеререть, сам запрос посмотрел 700 строк. А план вообще не видно конца.

пулер есть конечно, но за настройки не ручаюсь, это надо ковырять.

Вот тут я не до конца понял например work_mem = 4мб, как work_mem работает в разрезе сессий. Допустим в одной сессии выполняем запрос, для сортировки и тд, ему требуется например 1мб, зашли 1000 пользователей и одновременно юзают запрос с сортировкой получается 4бм будут в ОЗУ, а 996мб будет использоваться диск? Честно говоря не нашел каких то документов, почитать на эту тему

А то, что из 300 селектов в pg_stat_activity 100 в состоянии idle in transaction это нормальная ситуация? С пониманием этого момента тоже пока трудно.