Другой момент, который хотелось бы озвучить. Как упоминали ранее, лучше

иметь в команде DBA, который будет в этом разбираться. Но на данный момент это не представляется возможным. С Postgres мы работаем в первый раз, и тонкостей, естественно не знаем, и переходить на другую базу, скорее всего, не будем в виду того, что придётся так или иначе переписывать воркеры и другие сервисы, и дополнительно это не отменяет того факта, что в другой базе не будет аналогичных проблем.

Возвращаясь к сути вопроса: увеличение RAM и количество соединений. В данный момент необходимо запроцессить исторические данные. Записей около 100 млн. Конечно же это нужно сделать в кратчайшие сроки, чтобы можно было выполнять дальнейшую работу по анализу полученных данных и сделать и итоге MVP, которое покажет суть работы.
У нас имеются воркеры, которые могут обрабатывать в сумме до 5,000 записей (и больше, в зависимости от поднятых машин) в секунду. Операции которые выполняют воркеры — самые простые, без кучи связей (4 таблицы всего, в сумме 21 колонок):
1. Проверка записи на существование в базе
2. Добавление записи в базу
Такие процессы выполняются без батчей. Какой pool_size указан в воркере, столько операций insert/exists выполняется одновременно.
Отсюда и вытекает необходимость в большом количество подключений к базе. На данный момент переписывать логику работы воркеров трудозатратно и, по сути, бессмысленно, т.к. нужно проделать эту операцию (прогон исторических данных) всего один раз. С дальнейшими ежедневными обновлениями справится и 1-2 воркера на каждый сервис, которые, естественно, базу в текущем положении не положат.
И опять возвращаясь к вопросу: возможно ли в данный момент настроить Postgres так, чтобы он не падал от 3-4 тысяч активных подключений к нему? Конфигурация база может быть любой: CPU, RAM, Storage.
Из возможных вариантов пробовал PGTune. Но поскольку я это пробовал всё ещё на Google Cloud SQL, то некоторые параметры настроить было невозможно. Возвращаясь к использованию Bitnami (будет собственный сервер с возможностью настройки postgres.conf) — поможет ли PGTune в данном случае? Указание RAM, CPU, количества подключений — и подтверждение изменения предложенных им [PGTune] конфигов. Либо нужно что-то другое?

P.S. Прикрепляю график RAM за весь день. Можете сравнить его с тем, что было в предыдущий раз. Стало хуже, хоть и изменилась только база. В моменты, когда графики идут на спад — база недоступна — воркеры висят. В прошлый раз спад был практически моментальный, из-за чего воркеры начинали работать в течение нескольких минут.

вы не пробывали использовать pgbouncer или yandex odyssey?

Нет. Про yandex odyssey первый раз слышу, а про pgbouncer, естественно, слышал. Но что это и как с ним правильно работать тоже нет представления. Сейчас вся работа с базой строится на SQLAlchemy (python)

почему вы считаете, что график использования памяти — проблемный? есть ошибки в логах?

https://pgday.ru/presentation/152/59649587644b9.pdf

> 1. Проблема с ООМ осталась (ниже более подробно) полагаю это оно

Как упомянул @lesovsky — да, это оно и есть

Спасибо, посмотрю

> возможно ли в данный момент настроить Postgres так, чтобы он не падал от 3-4 тысяч активных подключений к нему? 1 тыс ядер. В противном случае будет тормозить, без вариантов.

А это, вообще, postgres или всё-таки форк (я забыл)? Потому что если второе, это обсуждению тут, по-хорошему, не место.

Не совсем понимаю, о чём вы

О том, что если это не настоящий PostgreSQL, а какой-то из его (десятков) forks, то это a) off topic и b) обращаться за помощью следует в техподдержку организации-разработчика. Так это fork или нет?

Вы про Bitnami, я так пологаю? Если да, то не fork, насколько я могу судить. https://bitnami.com/stack/postgresql/containers

Да, я про это. Понял, спасибо!

> Прикрепляю график RAM за весь день. Это график, конкретно, чего?

Mooner
График RAM, когда целый день были запущены ~50 маш...

График конкретно какой величины "RAM"? Измеренный чем? Понимаете, дело в том, что большинство из подобных графиков измеряет погоду на Марсе, грубо говоря. :(