Ещё раз поясню, что не я выбирал и не покупал

этот сервис. Работаю с тем, что предоставил заказчик. Предполагаю, что кто-то из 5 с половиной тысяч здесь присутствующих работал с сервисом Я.Облака.
Да и потом, я задал конкретный вопрос: стоит ли увеличивать shared_buffers с 8 Гб при наличии 48 Гб оперативы? Общий размер таблиц с индексами порядка 36 Гб.
К счастью, параметры PostgeSQL можно менять через консоль.

1. почему вы говорите про “наличие 48GB оперативы”? на картинке больше на 128GB похоже. 2. базе даём либо 25% памяти (остальное ОС кэширует), либо 75%. 3. это при сусловии, что кроме базы никого нет на сервере. если ещё что-то, готовых рецептов нет

1. Исходя из заказанных характеристик. Суммирование странное на дашборде. Думаю, Total - это общая цифра доступной памяти. 2. 25% памяти - это shared_buffers? Т.е. в моём случае лучше докинуть с 8 до 12 Гб? И можно поэкспериментировать с 36? 3. Поскольку это Managed Service for PostgreSQL, вряд ли внутри спрятали что-то ещё, кроме СУБД.

до 12 можно, больше не надо — там очень просто в ногу выстрелить.

Спасибо! В ногу не надо ))) То есть я могу предположить, что сейчас основная часть данных кэшируется на уровне ОС. А buffers используются довольно слабо.

25% или 75% — это из того соображения, что буферы линукса и буферы постгреса работают примерно одниаково, и если дать половину памяти, то все будет закешировано два раза.

Понял, спасибо, не знал.

Попробовать и сравнить-то можно. Но для этого мониторинг должен быть, само собой. И измениться всё может сильно, в принципе (т.е. оптимальная настройка может отличаться от default раза в три, например).

Поднял shared_buffers до 36 Гб при оперативе 48Гб. Получил гораздо лучше результаты, чем при 8-12 Гб. Но не даёт мне покоя мысль про выстрел в ногу ))) Мой кейс - это аналитическая БД. Две денормализованных витрины 10 Гб и 12 Гб. Обновление витрин небольшими порциями 1 раз в 3 часа (DELETE + INSERT). К витринам подключена BI-система, которая шлет множество запросов в БД (отчеты с Live Connection, 10-12 сессий на пользователя). Каждый запрос обернут в курсор with hold (пробую бороться с этим, пока оживил запросы поднятием сursor_tuple_fraction до 0.9). Изначально всё это хозяйство жило в GreenPlum, но осилить поток в сотни мелких запросов не вышло. Какие риски 75% shared_buffers в моем случае?

1. аналитическим запросам нужна память. нужно следить, чтобы shared_buffers + сессии * work_mem было бы в пределах доступной памяти, чтобы не призвать OOM. 2. вам следует посмотреть как себя чувствуют чекпойнты при таких shared_buffers, у меня был кейс, когда дискам и системе было легче при низком значении shared_buffers, т.к. запросы всё равно много читали с дисков при любых shared_buffers

> Получил гораздо лучше результаты, чем при 8-12 Гб. Ожидаемо, да. > Какие риски 75% shared_buffers в моем случае? Ну... могут иногда какие-то запросы [временно] выдавать ошибки при нехватке памяти (если уже выполнены базовые настройки). Перезапустятся, большое дело — а настройки можно под них "подточить". ;)

1. work_mem стоит дефолтное (4Мб), ограничение в 1000 сессий, в реале ожидаю не более 300-400 одновременно. PgBouncer в режиме Transaction, на вид отрабатывает нормально. Т.е. 36 + 4 Гб в текущем раскладе. 2. Вот чтения с диска у меня вообще практически нет. Чекпойнты не смотрел. Сейчас посмотрел SELECT * FROM pg_stat_bgwriter, но там статистика с декабря 2020. Я так думаю, что нужно её сбросить и посмотреть на текущую картину?

К счастью, все запросы более-менее известны. База используется исключительно приложением, с ad-hoc туда не лезут в принципе, для этого есть GreenPlum.

> work_mem стоит дефолтное (4Мб), "Типичные" запросы можно посмотреть — может, каждый использует по 20*work_mem. ;) > ограничение в 1000 сессий, в реале ожидаю не более 300-400 одновременно. Это слишком много, почти наверняка. В норме это PgBouncer должен решать. Вы (с помощью мониторинга) выясните, сколько бывает реально одновременных подключений (пик). И примерно так и ставьте (с небольшим запасом).

Сорри за нубский вопрос, как посмотреть использование work_mem? Explain analyze? ) По сессиям - в облаке автоматом стоит 1200 сессий на всё для этой конфигурации хоста, больше нельзя. Приложению оставил 1000.