а почему не используете pgbouncer?

Быстрый поиск привел к тому, что я не знаю, как его можно/надо использовать с текущей реализацией воркеров

Доброго дня. Продолжаю разбираться с коннектами и нагрузкой на базу. Вчера предлагали изучить yandex odyssey, pdf просмотрел, но, естественно, мне далекому от этого всего человеку, мало что было понятно.
В данный момент переписал один из воркеров так, чтобы использовалась база тогда и только тогда, когда это требуется. Один воркер имеет 50 потоков и пул из 50 подключений к базе. Самая минимальная "машина" (1 процесс 1 поток) обрабатывает ровно 1 операцию в секунду. После изменения количества потоков с 1 до 50, стало, соответственно, 50 о/с.
По графикам нагрузки на базу стабильно висит 200 активных подключений (активно 2 воркера, у каждого воркера 2 процесса по 50 потоков). Вопрос в следующем: использование ОЗУ растёт линейно с течением времени — так и должно быть? Либо что-то не утилизируется? Либо тут это так не работает? Это ведь в конечном итоге приведёт к ООМ, не так ли?

> Вопрос в следующем: использование ОЗУ растёт линейно с течением времени — так и должно быть?

Использование ОЗУ где и чем (мне кажется, или Вы даже и в прошлый раз так не объяснили, чем и что измеряете)?

это пул соединений. Я думаю его можно использовать с чем угодно.

привет всем!  поставил настройки в postgres

max_connections = 1000
max_files_per_process = 1000
default_statistics_target = 1000
maintenance_work_mem = 2050MB
effective_cache_size = 20GB
work_mem = 1200MB
wal_buffers = 16MB
temp_buffers = 256MB
shared_buffers = 4GB
bgwriter_delay = 20ms
bgwriter_lru_maxpages = 400
bgwriter_lru_multiplier = 4.0
effective_io_concurrency = 333
max_worker_processes = 8
max_parallel_workers_per_gather = 4
max_parallel_workers = 8
max_parallel_maintenance_workers = 4
seq_page_cost = 0.5
random_page_cost = 0.5
autovacuum = on
autovacuum_max_workers = 8
autovacuum_naptime = 20s
min_wal_size = 512MB
max_wal_size = 2GB

но при запросе

SELECT "account_profile"."user_id",
       "account_profile"."division_id",
       "account_profile"."tel",
       "account_profile"."update_pass",
       "account_profile"."gas_stations_id",
       "account_profile"."ldap",
       "account_profile"."main_unit_id"
  FROM "account_profile"
 WHERE "account_profile"."user_id" = 1
 LIMIT 21

Время: 65,09089469909668 ms
какие настройки не правильно сделал где нужно увеличить или сжать подскажите

Вот этим: https://cloud.google.com/sql/docs/postgres/monitor-instance

Доброго дня. Продолжаю разбираться с коннектами и нагрузкой на базу. Вчера предлагали изучить yandex odyssey, pdf просмотрел, но, естественно, мне далекому от этого всего человеку, мало что было понятно.
В данный момент переписал один из воркеров так, чтобы использовалась база тогда и только тогда, когда это требуется. Один воркер имеет 50 потоков и пул из 50 подключений к базе. Самая минимальная "машина" (1 процесс 1 поток) обрабатывает ровно 1 операцию в секунду. После изменения количества потоков с 1 до 50, стало, соответственно, 50 о/с.
По графикам нагрузки на базу стабильно висит 200 активных подключений (активно 2 воркера, у каждого воркера 2 процесса по 50 потоков). Вопрос в следующем: использование ОЗУ растёт линейно с течением времени — так и должно быть? Либо что-то не утилизируется? Либо тут это так не работает? Это ведь в конечном итоге приведёт к ООМ, не так ли?

Хмм... Вы же, вроде бы, переходили на настоящий postgres, или я путаю?
И Вы знаете, что именно эта штука измеряет (я вот нет)?

Вы close() не забываете вызывать после каждого запроса?

Мне кажется, вы как-то неправильно с пулом SQLalchemy работаете. Какие у вас значения max_overflow и pool_size?

Просто pool_size - это то количество коннектов, которое захватит пул приложения при его старте (т.к. это постоянно занятые подключения). А max_overflow - это количество, которое он может использовать в принципе при необходимости. То есть, условно говоря, если вы указываете pool_size = 200, то приложение при старте эти 200 коннектов и займёт для пула вне зависимости от того, делаете вы запросы к БД или нет.

Пока всё же решил остаться на Cloud SQL ввиду того, что если устанавливать через тот же Bitnami, то придётся настраивать практически все параметры базы. А какие именно надо — можно конечно посмотреть на текущие параметры в облаке, но получится аналогичная база, вот

Да, это я понимаю. И в этом неверная логика? В том плане, что нужно выделить, условно, 200 адресов для 200 потоков?

Тогда Вас ждёт техподдержка google, по-хорошему.

> но получится аналогичная база, вот

Получится настоящий PostgreSQL, а не https://cloud.google.com/sql/docs/postgres/features#differences-pg
И сообществу будет куда интереснее вам помогать, IMHO. ;)

А сколько именно - надо подобрать экспериментальным путём.

Да, вот экспериментами занимаемся уже которую неделю