Другой момент, который хотелось бы озвучить.
Как упоминали ранее, лучше иметь в команде 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?

Другой момент, который хотелось бы озвучить.
Как упоминали ранее, лучше иметь в команде 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 за весь день. Можете сравнить его с тем, что было в предыдущий раз. Стало хуже, хоть и изменилась только база. В моменты, когда графики идут на спад — база недоступна — воркеры висят. В прошлый раз спад был практически моментальный, из-за чего воркеры начинали работать в течение нескольких минут.

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

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

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

> Из возможных вариантов пробовал PGTune.

pgtune вам точно не поможет, т.к. он дает базовые рекомендации, и не учитывает особенности ворклоада

Hi everyone, I just want set constraint mode as  DEFERRED for CHECK constraint, is it possible? it should validate end of transaction

Другой момент, который хотелось бы озвучить.
Как упоминали ранее, лучше иметь в команде 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 за весь день. Можете сравнить его с тем, что было в предыдущий раз. Стало хуже, хоть и изменилась только база. В моменты, когда графики идут на спад — база недоступна — воркеры висят. В прошлый раз спад был практически моментальный, из-за чего воркеры начинали работать в течение нескольких минут.

Другой момент, который хотелось бы озвучить.
Как упоминали ранее, лучше иметь в команде 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 за весь день. Можете сравнить его с тем, что было в предыдущий раз. Стало хуже, хоть и изменилась только база. В моменты, когда графики идут на спад — база недоступна — воркеры висят. В прошлый раз спад был практически моментальный, из-за чего воркеры начинали работать в течение нескольких минут.

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

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

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

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

у вас есть мозможность менять sysctl на хосте с БД? Если да, то попробуйте выставить vm.overcommit_memory=2 - в такой конфигурации 1) можно снизить (но не избежать) риск OOM, 2) вместо OOM запросы будут падать по менее фатальной системной ошибке и в логе постгреса можно будет увидеть тексты запросов и попытаться уже подебажить их (см. explain).
Ну и нужно подумать как побить обработку на более мелкие куски, если вам таки не хватает памяти.